I've been having a world of trouble getting Khmer fonts (an Indic script of Cambodia) to render reliably on the web across platforms (Mac, Windows, Linux).
Google web fonts recently added Khmer, which seems like the best bet. However, I have not been successful getting Khmer fonts to work on any Mac or Linux system. I can get them to work on Windows by installing the Khmer Unicode installer from http://khmeros.info but not by just including Google's font in an HTML file.
For example, see this screenshot of the Google web fonts page on a fresh Windows installation. You can see that the default Windows Khmer font (uuuuugly!) is being used instead of Danh's pretty fonts.
I have another test file here: http://dl.dropbox.com/u/634/khmer_test.html. For the first test, you should see something like this for both the web font and the default system font (assuming you have Hanuman installed). I have yet to find a system where both examples work reliably.
Any help would be greatly appreciated. My primary goal is to get this working on a website; a secondary goal is to get Khmer (and other Indic fonts) working in a PDF generator like iText (although I am aware iText itself does not support Indic fonts -- I'm hoping something similar does).
Every Cambodian Windows users are always delete the font name called: KhmerMool and Khmer Kampot. Then they change the default Khmer font in regedit too. You can check at http://thelifeandwork.blogspot.com/2010/01/changing-default-khmer-font-in-windows.html . I'm not sure about Khmer font and other Indic font in PDF. I always have problem when i copy Khmer unicode from PDF to put in OpenOffice or Office Word or LibreOffice.
Khmer Unicode displays on the web, it will always solve now by Google Webfont, please refer to that.
And if you want to have Khmer display in PDF by converting using iText, you can see following post:
Khmer Unicode in iText
http://ask.osify.com/qa/287
They are currently not yet support the display yet.
But, just today I can get it works by modifying the source code of iText (5.5.4-SNAPSHOT) as I just stated in my post: http://ask.osify.com/qa/613, not yet be able to publish since it's just start in testing around.
Updated 13/01/2016
I have added the source code sample for the rendering: http://ask.osify.com/qa/613
The rendering customization with iText for Khmer Unicode added in github: https://github.com/Seuksa/iTextKhmer
Related
I'm building a web page that uses Google WebFonts (open sans) on a PC and it works perfectly, but when I try it on a mac computer it shows a question mark within the text. Why is this?
The character you are seeing is the replacement character, which is used when a font does not contain a particular Unicode character, in this case, "ñ" AKA U+00F1 AKA "Latin small letter n with tilde".
Google Open Sans does contain this character, so it seems that Safari is not correctly getting the font from the web. The rendering engine is then reverting to another font, and that one is missing the offending character. You will be able to check in dev tools on your mac which font is being grabbed by your script.
I checked the script annotation you posted in the comment to your question. You are returning the fonts in the woff2 format. It turns out that woff2 is not supported in Safari as of version 9, but woff is. I therefore recommend changing the format to woff and serving it to your page locally:
Download the script you posted (http://fonts.googleapis.com/css?family=Open+Sans:300,400,500,700)
Save it as a css file (e.g. fonts.css)
Find-and-replace woff2 to woff
Save the file
Add it to your web project (however you add your other files)
Replace #StyleSheet({"fonts.googleapis.com/css?family=Open+Sans:300,400,500,700";}) with a reference to this newly uploaded file.
Solved! One of the developers had its Eclipse not set to UTF-8 so the file transfer using Git wasn't working properly...to check, go to Preferences>General>Workspace>Text file encoding and set to UTF-8
I have integrated some hints (a prep handler to update the cvt and glyph instructions (simple MIAPs to copy the cvt values to specific points) into a custom TTF font.
I changed the fonts via Python fontTools.ttx
The font and the hints work perfectly when I test the font in TrueTypeViewerQt.
The font (and the hints) work also in PIL.
I can also see the hints in FontForge (for prep and the glyphs), but debugging them just shows "".
I also get this message in the console window:
SplineFontPieceMeal() going unhinted...
When I now use the font from a PDF file (written via reportlab), the font is used, but my hints seem to be ignored by Acrobat Reader, Ghostscript, mudraw, Chrome Web Browser (integrated PDF view), or an own application based on PDFium.
Then font exported from the PDF (via mutool) still contains the hints which work in TrueTypeViewerQt.
PDF: https://www.dropbox.com/s/qn3iooazsq1z2w5/d85.pdf?dl=0
Font: https://www.dropbox.com/s/p6qwug9h6vcgps0/testbar.ttf?dl=0
Any ideas?
I'm using windows 7 and recently downloaded and installed LyX and MiKiTeX to my computer in addition to Culmus Hebrew fonts for LyX.
However, when I want to compile a Hebrew Article it gives me an error:
\begin{document}
I wasn't able to read the size data for this font,
so I will ignore the font specification.
[Wizards can fix TFM files using TFtoPL/PLtoTF.]
You might try inserting a different font spec;
e.g., type `I\font<same font id>=<substitute font name>'.
Can't fix it for months now.
Appreciate your help!
Following the instruction in this link ( https://github.com/EllisLab/CodeIgniter/wiki/PDF-generation-using-dompdf ), I always encounter an error when opening the pdf file created. The error message is:"Cannot extract embedded font 'TradeGothicLT-CondEighteen'.Some characters may not display or print correctly. " and when i click OK, the pdf displays black background and when i start highlighting the body, it captures the text but text are in black font-color. what should I do to get rid of this error?
There may be something wrong with your font cache, located at dompdf/lib/fonts/dompdf_font_family_cache.php (though the exact file name depends on your release and whether you have loaded fonts). This file tells dompdf what fonts are available for use in the PDF. If this file references a font that isn't actually available you can run into major issues on viewing. You may need to re-load your font files. Take a look at the Unicode how-to for an overview of using embedded fonts. This document hasn't been updated to reflect changes implemented in dompdf 0.6.0 beta 3, but the information is still pertinent.
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...