[PATCH] Re: [Swftools-common] pdf2swf issue with Font Display on WinChar

Some very sharp folks (not me) in the poppler and freetype community figured out that the FreeType "auto-hinter" handles "tricky" CJK fonts based on the font's name. Some PDF generators are broken and either don't include the font name correctly or use the non-english font name.

So FreeType doesn't detect it as a tricky font, doesn't turn on auto-hinter, and the font looks garbled. Evince (Gnome PDF viewer) suffers from the same issue.

Xpdf, unlike poppler, forces hinting enabled. That's why the same Chinese fonts looked better in Xpdf than pdf2swf.

The short term fix:

I'm not sure why, but swftools xpdf-changes.patch disables FreeType hinting in xpdf/SplashFTFont.cc:

- if (FT_Load_Glyph(ff->face, gid, FT_LOAD_NO_BITMAP)) {

+ int error = 0;

+ if ((error=FT_Load_Glyph(ff->face, gid, FT_LOAD_NO_BITMAP|FT_LOAD_NO_HINTING))) {

By removing "|FT_LOAD_NO_HINTING", pdf2swf will use Xpdf's default (turn hinting on). Problem is, I don't understand why FT_LOAD_NO_HINTING is being set in the first place in swftools. Is there a problem with some latin fonts in pdf2swf?

See attached patch (apply to git head, before xpdf-changes.patch is applied) for how to fix. It's also easy enough to produce a patch directly against post-patched xpdf/SplashFTFont.cc, so you can patch against an existing swftools release like 0.9.1.

The correct fix:

Freetype 2.4 includes a number of TrueType hinting enhancements due to some recently expired patents. FreeType 2.4.3, recently released, includes changes to handling of "tricky" CJK fonts which have no name or a non-latin name. I have not yet tested this myself.

As far as I know, this code isn't available in any mainstream Linux distribution yet. So we need to wait for that to happen, or ask Linux distributors to backport the fix.

On Tue, Oct 19, 2010 at 3:21 AM, Irving Popovetsky <address@hidden> wrote:

Chris,

On Fri, Oct 15, 2010 at 7:13 AM, Chris <address@hidden> wrote:
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

From:	Irving Popovetsky
Subject:	[PATCH] Re: [Swftools-common] pdf2swf issue with Font Display on WinCharSetFFFF-H (CID TrueType) fonts
Date:	Tue, 9 Nov 2010 13:51:50 +0800