[fusiongyro]

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]

Yes, it's all wrong on Evince too.

Chrome PDF reader displays it correctly, though.

[chrismorgan]

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

[brechtm]

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 :)

[rhythmvs]

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

[viraptor]

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.