The Into Pdf seems to be broken
michaelko opened this issue · 7 comments
At last it does not look like i think it should on my computer in neither evince nor firefox. I'm talking about this file
RinohType handles OpenType fonts as a CID font, using Identity-H encoding. This enables accessing all of the 65536 glyphs in an OpenType font, as opposed to only 256 when using a standard encoding. I opted to do this to make handling of different scripts much easier (internally).
When you replace texgyretermes-regular.otf with Windows's times.ttf in rfic2009style.py, the generated PDF is rendered correctly in Firefox. Both are OpenType fonts, but the key difference between them is that the former contains Type1 outlines (CFF/Postscript OTF) and the latter contains TrueType outlines (TrueType OTF). Both are included as a CID font in RinohType and use Identity-H mapping, so this might indeed be a bug in Evince and PDF.js (see also this comment by rhythmvs).
Can you try replacing texgyretermes-regular.otf with a TrueType font and see what happens in Evince?
I have not been able to find an example PDF file with a CFF OTF embedded using the Identity-H encoding, so I cannot verify whether RinohType makes a mistake or whether this is a bug in Evince/PDF.js. All I know is that the following applications render the PDF correctly:
- SumatraPDF
- Adobe Reader
- PDF-XChange Reader
- Foxit PDF Reader
- Ghostscript (doesn't report any errors)
If this is indeed a bug in the Evince/PDF.js, I would rather not change the current handling of OpenType fonts as it would need a lot of code to work around the 256 glyph limit. I did not find a known bug in Poppler (the PDF library that Evince uses) that describes this problem though.
FYI, PDF.js in Firefox 43.0.1 (Arch Linux) renders the intro_tempate.pdf correctly! However, Evince 3.18.2 (poppler 0.39.0) still has the bug and looks just like on the screenshot provided above. You seem to understand the issue better, so could you please file the bug on Poppler's bugtracker?
Yes, I noticed recent versions of PDF.js do indeed render RinohType PDFs correctly. Didn't think of updating this issue though, so thanks!
Poppler bug reported: https://bugs.freedesktop.org/show_bug.cgi?id=93559
PDF.js fixed this problem somewhere between v1.0.1149 and v1.0.1212 (changes).
Possibly fixed by mozilla/pdf.js#5770
The poppler bug has been fixed.
I can confirm that the PDF works fine now with Poppler 0.41 release!
Thanks for verifying frol!