No, I think you correct. However, I was wondering if you thought this was the
result of incorrectly drawn substitute fonts, or incorrectly rendered to grid
ones, i.e. bad primary pixel interpolation..
I can confirm that it's definitely not substituting. See below.
Presumably the two fonts, when viewed in a font editor, are exact copies? Do
you get the same effect if you render the font with font2swf?
Interesting.
I don't have the original font (probably a built-in Chinese windows font). I used FontForge to extract the font from the PDF. Fontforge complains that it doesn't understand the "fpgm" and "prep" codes in the font, and also displays them incorrectly:
It's my understanding that the fpgm and prep codes are programmatic instructions stored in the font to adjust the brush stroke size and layout.
Took the extracted font and saved it (without modification) to a TTF. interestingly, font2swf displays it correctly:
Now, why would pdf2swf and font2swf behave differently for the same font?
ttbomk, yes. You just need to tell xpdf where to find them, by setting in xpdfrc,
http://www.foolabs.com/xpdf/problems.html
It looks like xpdf ignores any entries like "displayNamedCIDFontTT" when using embedded fonts. I'm trying to see if FontConfig might help, but for some reason the #ifdef HAVE_FONTCONFIG stuff isn't working in lib/pdf/CharOutputDev.cc. Digging into that now.
-Irving