Hi Mehdi

Interesting problem. Apparently, the overwhelming majority of TrueType
fonts map glyph index 1 to ".null" and glyph index 2 to "nonmarkingreturn"
(for carriage returns and such). Your version of the Frutiger 45 Light
font apparently doesn't but has "space" on glyph index 1. 

Those three "blind" indices have been in FOP's codebase since the
addition of CID subsets in 2001:

Funny that something like this shows up after so much time.

Anyway, since we only need to embed a .notdef as index 0 and the glyphs
we really need I think it is safe to remove the fixed indices 1 and
2 since this whole thing then seems to work for both kinds of fonts.

I'd say, put your patch in Bugzilla!

On 17.03.2011 17:27:22 mehdi houshmand wrote:
> Hi Guys,
> I found an issue with a True Type Font in PDF, I have attached a PDF
> with the possible bug (buggy.pdf) and with my "fix" (fixed.pdf). The
> issue is that if you copy/paste the text from the normal-weighted font
> (top line) of the PDF, the " " (space) and "!" (exclamation mark)
> characters are mapped to unicode index \uFFFF.
> Initially I thought this was a bug in the font, so I looked at the
> "cmap" table in the font to see what unicode index these glyphs were
> mapped to, and I found that they were the 2nd and 3rd entries in the
> "cmap" table. This tickled my curiosity because all the fonts I
> remember (and I checked a couple to be sure) have the first 3 glyphs
> mapped to \u0000 or \uFFFF and in their CID is .notdef. The BOLD
> version of the same font (in both PDFs) works fine, and as expected
> the first 3 glyphs are mapped to \uFFFF, \u0000 and \u0000
> respectively.
> I also checked the code-base and in o.a.f.fonts.CIDSubset has the
> following lines of code:
>     /**
>      * Adds the initial 3 glyphs which are the same for all CID subsets.
>      */
>     public void setupFirstThreeGlyphs() {
>         // Make sure that the 3 first glyphs are included
>         usedGlyphs.put(new Integer(0), new Integer(0));
>         usedGlyphsIndex.put(new Integer(0), new Integer(0));
>         usedGlyphsCount++;
>         usedGlyphs.put(new Integer(1), new Integer(1));
>         usedGlyphsIndex.put(new Integer(1), new Integer(1));
>         usedGlyphsCount++;
>         usedGlyphs.put(new Integer(2), new Integer(2));
>         usedGlyphsIndex.put(new Integer(2), new Integer(2));
>         usedGlyphsCount++;
>     }
> So I checked the specification and no where does it suggest that the
> first THREE are reserved, it does however say that CID 0 should be
> .notdef. (see quote below, p340 of PDF spec).
> "Every CIDFont must contain a glyph description for CID 0, which is
> analogous to the .notdef character name in simple fonts (see “Handling
> Undefined Characters” on page 355)."
> My question is this, is this a FOP bug or is this a bug in the font
> we're using? If it's a fop bug, I'd be more than happy to fix it
> (delete the 6 lines and change the method name). If, however, it's a
> font bug, then which spec should I be looking at? What is the bug? I
> should also mention, that I started with the TTF spec and this doesn't
> suggest that any glyphs are reserved.
> Any help on this would very much be appreciated,
> Mehdi

Jeremias Maerki

Reply via email to