I've got yet another problem with Crystal Reports 2008. This time, when I'm exporting to PDF from CR2008 from the company server, a font, Dax-regular, gets blurry. It's not completely illegible, but it is smudged out, like the ink got wet.
Another problem is that certain fonts, which I am sure are not DRM-protected or anything like that, when exported are random gibberish symbols, not readable text. This seems to be a problem with the embedding of fonts in CR.
I believe the smudged fonts could be caused by a fix I had to perform because of the small text bug that others have reported (http://www.arcanadev.com/support/kb/K00000394.aspx).
What can I do to troubleshoot and, if possible, fix this problem?
Thanks!
To my experience I haven't seen anything like that all fonts are properly exported to PDF if you provide any screenshot it would be more helpful.
Your second issue of symbols there are some fonts when you type will provide you symbols may be you are using those....
Sorry if I understood yout issue in a wring way
Related
It's really weird, but for some reason when I try to install FA as a font on my system, it displays all the icons as a square with a question mark in it. Have a look:
Even after installation, it's the same:
The strange thing is, FA icons display fine in my browser, as long as they are
Anyone know why this is happening and what I can do to fix it?
Well, finally! I found an answer for this over at the fortawesome github issues. It's as simple as installing the font, ignoring the question marks, and then using the fontawesome cheatsheet to copy and paste the icons in your document.
I'm so glad I found an answer to this! I didn't even think of trying to just copy and paste the icons after installing the font.
I am using Materialize to style some of my web pages. I have noticed that Roboto font does not render correctly in Firefox (v43.0.3), but looks fine in Chrome. Both browsers are downloading the woff2 font file from my server, which this question seems to indicate should be the optimum choice for modern browsers.
Chrome rendering:
Firefox rendering:
(I realize these low-res screencaps are not the best reproduction, the differences are much more apparent in the actual browsers.)
In the Firefox console, I receive a string of error messages similar to:
downloadable font: GSUB: too large substitute: 65535 (font-family: "Roboto" style:normal weight:normal stretch:normal src index:1)
downloadable font: Layout: Failed to parse lookup subtable 0 (font-family: "Roboto" style:normal weight:normal stretch:normal src index:1)
downloadable font: Layout: Failed to parse lookup subtable 0 (font-family: "Roboto" style:normal weight:normal stretch:normal src index:1)
No complaints from Chrome.
As I am not at all familiar with the intricacies of font rendering, I was hoping that someone with some knowledge in that area might have an idea what the problem is based on the error messages from Firefox.
I finally had some time available to look into this a bit more, it appears that some of the font files in the materialize repository are defective. I was able to completely resolve this issue simply by replacing the font files in the dist/font/roboto directory with the same files available at roboto-fontface-bower. Just pull from any of the version branches v0.3.0 or better.
Hope this helps anyone else who has been frustrated by this.
To me it looks like either the woff2 file has wrong offsets to the internal font tables or Firefox reads wrong offsets when parsing the offsets.
The GSUB table mentioned in the error message cannot be the main reason for the rendering problems, because it only defines glyph substitutions (like ligature composition and decomposition, alternative glyphs for the same char code, etc). The table does not contain any rendering information for standard glyphs, so if only that table fails to load, rendering of standard text should not be affected. Details about the GSUB table can be found in Microsoft's OTF specification.
Also, I get another error message when looking at this website:
http://gwt-material-demo.herokuapp.com/
Firefox tells me that there is something wrong with the OS/2 table (which contains Windows font metrics). This is a completely different part of the font file, which again indicates that there is something wrong with the font structure or with reading the font structure.
So there are two things you can do:
Do not use the woff2 file.
Notify the Roboto and Firefox developers about the issue and hope that they will find the cause for this bug and fix it.
I am using Century Gothic font in my HTML and then converting it in to PDF. It works perfectly on my mac, but on my Slackware 14.1 server, when I convert the HTMl in to the PDF, the font is not rendered as smoothly as it should be.
I read several ways to include non-standard fonts in the HTML, as #font-face, or adding the entire font in the CSS file as an encoded font and both these methods worked for me in the HTML. The HTML is rendered perfectly in the browser, it's the PDF which is not getting a correct Century Gothic. Any help is highly appreciated.
Thank you
I did some research too and it seems that this is a known bug with qt-webkit.
See the issue documentation here:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2193
Sorry to not have better news for you. Maybe just try with a supported font that's close enough to what you like it to look?
I'm having troubles figuring out why Chrome and Firefox are rendering some things differently. Below are images of a part of my project as seen in Firefox (top) and Chrome (bottom). MathJax renders everything as the page is loading and once everything has been processed and typeset, it is displayed on the page. So I'm not sure if this is my fault of MathJax's fault. Anyway here are the images...
... if you would notice, the square with black border is different in Chrome, and in a bad way. Any ideas as to why this might be happening? The following is output from Chrome's console...
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Regular.svg#MathJax_Main-Regular:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Bold.svg#MathJax_Main-Bold:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Italic.svg#MathJax_Main-Italic:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Math-Italic.svg#MathJax_Math-Italic:-1
etc...
The code for rendering the square alone, without all the other fancy stuff, is relatively simple...
<div id="square">
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<mo id="tag0" class="expand">◻</mo>
</math>
</div>
... and then I tell MathJax to render it...
MathJax.Hub.Queue(["Typeset", MathJax.Hub, "square"]);
... and MathJax does its thing (I have no control over the rendering MathJax does). So I don't quite know where the problem is.
I know this is a very strange and very specific question but I'm hoping someone in the Stack Overflow community might have some idea or has dealt with MathJax previously. Hopefully some brainstorming will help resolve this issue.
The box you are seeing Chrome is the "missing character" symbol. The MathJax fonts don't include U+25FB, and so Chrome is showing the missing symbol. It looks like Firefox is finding the character in a different font and using that (or perhaps you have STIX fonts on the machine running Firefox but not the one running Chrome, and MathJax is using that). Browsers differ in their ability to find alternative fonts for symbols that aren't in the MathJax fonts.
In any case, try using U+25A1 instead of U+25FB and see if that works better for you.
Davide
MathML will come to Chrome natively, WebKit has been working on it for some time now:
http://www.webkit.org/projects/mathml/index.html
I guess this question should be marked as a bug for MathJax. Hopefully soon, there would be a native solution.
I do not have a real answer, however rendering differences among browsers are nothing new. I use Firefox, Chrome, Opera, IE (in that order), quite often one of the browsers renders better than the rest. Firefox has some nice debugging plugins, you may try those (Firebug???). Warning: You may spend a lot of effort on this. If you get into troubleshooting CSS, ouch :).
I have a simple vb6 editor type application which has a richtextbox as the editor page. It allows users to key in stuff and the store it into a file which will keep all the text in RTF stored as CDATA in xml.
When you load back the file, it will read it off the xml and load back the rtf. We allow for unicode editing, but my problem is I have a user which is using Windows XP, and they have some problems reading the chinese characters. They show up as gibberish in their pc.
It displays fine in both mine and a coworker's. I've already checked that they have the proper regional language and settings in their system. The install files for east asian language is already checked. And they can see chinese words on websites and even type them out.
I feel like I'm missing something here but I'm at a lost on what to check next? Any ideas on what I could test or check next?
my bad for the poor description skills, if anything is not clear just ask me.
thanks.
~steve
That is weird. Try confirming that your user have the same version of RICHTXT32.OCX ?
Could be a problem with font?
Try using font that supports unicode characters (Arial Unicode).
Or try going to a website with chinese characters and paste it into richtextbox, save it to a file and try loading it from the file.
Does that work?
well they should because i packed the app in vs installer setup package.
and for fonts, it's sim sun, and i've already checked with the users that they do have the sim sun fonts under window/fonts.
Btw i've already updated that the data is actually stored in xml under CDATA, although the rtf chunk is kept as it is.
okie, this seems to be the solution although i don't know why. in my msi setup file i've included the riched.dll so when i installed it in, the dll acts up and screw up my chinese character in the richtext control.
but when i repack to exclude that dll file and reinstall using that setup, it seems to work now...