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.
Chrome PDF reader displays it correctly, though.
But I'm sure there's still a bug in my PDF font handing code :)
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.