5 ms·

The rendering of the test document is very strange in FF on RHEL 6 on Linux. Acrobat also gave me garbage for a few seconds and then somehow spontaneously figur

The rendering of the test document is very strange in FF on RHEL 6 on Linux. Acrobat also gave me garbage for a few seconds and then somehow spontaneously figured it out. I'm skeptical of these sorts of enterprises, but I'm glad the author took the challenge and I look forward to seeing where it goes.

1_player 13y ago
Yes, it's all wrong on Evince too. Chrome PDF reader displays it correctly, though.
- chrismorgan 13y ago
  I'm finding in evince the parts using character substitution and a custom font are not rendering at all.
brechtm 13y ago
I've noticed these problems on Linux too... On Windows, The PDFs render correctly on SumatraPDF, Adobe Reader, PDF-XChange Reader and IIRC also Foxit PDF Reader. But I'm sure there's still a bug in my PDF font handing code :)
- viraptor 13y ago
  It's also almost completely broken in pdf.js (firefox's new default viewer) - I guess that one should be the same between linux and windows at least.
- rhythmvs 13y ago
  That’s probably due to a known issue in pdf engines improperly handling fonts. Even Adobe’s own InDesign 4’s built-in pdf engine was plagued with that bug. [1] In the sample pdf, only the regular font gets messed up by affected pdf renderers (pdf.js in FF, …). That font is TeXGyreTermes-Regular, and it’s the only CID (composite) font. In the source, that font was an OpenType font (.otf), which, during pdf-creation, got converted into a CID double-byte font, resulting in messed-up Identity-H encoding. (CID double-byte fonts are really meant for huge Asian charset fonts, only.) Likely, the pdf engine used, wrongly assumes that all Unicode encoded fonts (.otf) contain huge Asian charsets, and thus converts them into CID. I guess most newer pdf renderers know to handle the issue, while the renderer used in FF e.a. doesn’t. The quick fix, at pdf creation, is to avoid fonts being converted into CID at all. [1] http://forums.adobe.com/message/1289456 http://forums.adobe.com/message/1289456

1_player 13y ago

Yes, it's all wrong on Evince too. Chrome PDF reader displays it correctly, though.

chrismorgan 13y ago
I'm finding in evince the parts using character substitution and a custom font are not rendering at all.

brechtm 13y ago

I've noticed these problems on Linux too... On Windows, The PDFs render correctly on SumatraPDF, Adobe Reader, PDF-XChange Reader and IIRC also Foxit PDF Reader. But I'm sure there's still a bug in my PDF font handing code :)

viraptor 13y ago
It's also almost completely broken in pdf.js (firefox's new default viewer) - I guess that one should be the same between linux and windows at least.
rhythmvs 13y ago
That’s probably due to a known issue in pdf engines improperly handling fonts. Even Adobe’s own InDesign 4’s built-in pdf engine was plagued with that bug. [1] In the sample pdf, only the regular font gets messed up by affected pdf renderers (pdf.js in FF, …). That font is TeXGyreTermes-Regular, and it’s the only CID (composite) font. In the source, that font was an OpenType font (.otf), which, during pdf-creation, got converted into a CID double-byte font, resulting in messed-up Identity-H encoding. (CID double-byte fonts are really meant for huge Asian charset fonts, only.) Likely, the pdf engine used, wrongly assumes that all Unicode encoded fonts (.otf) contain huge Asian charsets, and thus converts them into CID. I guess most newer pdf renderers know to handle the issue, while the renderer used in FF e.a. doesn’t. The quick fix, at pdf creation, is to avoid fonts being converted into CID at all. [1] http://forums.adobe.com/message/1289456 http://forums.adobe.com/message/1289456