Re-installed LyX and can't compile an Hebrew document - windows

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!

Related

Ghostscript PDF fonts becomes boxes in Adobe Illustrator where as its output is fine when opened in Adobe Acrobat

I need to convert the PDF of RGB color space to Grayscale using commandline tool supporting for Windows and Linux.
When i used Ghostscript the conversion is happening but when the output is opened in illustrator the fonts were shown as boxes.
Is there any solution option available in Ghostscript to overcome this font issue.
Is there any other commandline tool available for this conversion.
The font encoding is always built in is there any ways available to change it as ANSI encoding.Screenshot of font issue on illustrator VS the working scenario on acrobat
Pictures of the problem really don't help. You need to provide the following:
The version of Ghostscript you are using, and the platform (Linux, Windows etc), the word size of the version of Ghostscript and where you sourced this version of Ghostscript from (official Ghostscript download page, package, self-built binary).
An example file to reproduce the problem
The exact command line you used to reproduce the problem, and any supporting files required.
I suspect that your problem is that the original PDF file does not include the fonts that it uses, and that you have left SubsetFonts as true, and have left the AlwaysEmbed and NeverEmbed arrays untouched. This will mean that the new PDF file also does not include the fonts, which means that any PDF consumer must use a substitute font. The 'boxes' you refer to are /.notdef glyphs which are used when the font does not contain the glyph being requested.
Having the Encoding 'built-in' doesn't help with anything at all, it's the presence or absence of the fonts which matters. No, you can't change the encoding to 'ANSI', if you do that (assuming it isn't already WinAnsiEncoding) you'll see very similar problems to the ones you are complaining of here. You would also need to change the text character codes in the PDF file to be able to change the Encoding.
You could also raise this as a bug at https://bugs.ghostscript.com, where you will also have to supply an example file (as simple as possible) and all the other information listed above.

RTF using Hebrew in Z-Tree on Windows

I'm currently using z-tree (the Zurich Toolbox for Readymade Economic Experiments) for programming an experiment. I using a lot of formatting in Hebrew letters, which display correctly using my MAC. When I try running the experiment file on Windows, the Rich Text Formatting seems to not be encoded: sentences with numbers are all messed up.
I changed to locale language to Hebrew but I don't know what else should I do.
Any suggestions?
Thanks!

Why are my TrueType hints ignored?

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?

How do you reliably render Khmer (Indic) fonts on the web (and in PDFs)?

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

Why doesn't my CID (type 11) font work in GS8.61 on Windows

I have a customer in Macau that uses Windows EUDC for custom Big5 glyphs. I used Fontforge on Linux to convert the .TTE into a type 11 (CID type 2) font and created a custom CMap to map the Big5 code points to the correct glyph in the font. This all works fine and dandy in GS8.60 on Windows and GS8.61 - GS8.63 on Linux. When loading the font in GS8.61 on Windows I get a
/rangecheck error in /findfont in gs_cidfn.ps.
I've tried to use the EUDC.TTE font natively in ghostscript through the cidfmap with no luck, /invalidfont in /findfont. I'm hesitant to try to contact Ken Lunde, as this appears to be a problem specific to ghostscript. Does anybody know a workaround? Has anybody developed a patch so that I'm not reinventing the wheel here?
Edit: The /rangecheck error occurs in the .buildcidfont procedure. The .buildcidfont procedure has not changed from 8.60 to 8.61.
This seems to be resolved in GS8.63. Upgrading the client from 8.61 to 8.63 resolves this issue.

Resources