[Devel] Possible bug in ftxpost.c ?

[Jean-Christophe Dubacq]

Hi!

First, the interesting info:

I think ftxpost.c is wrong when reading the post table of a ttf font in
format 0x00020000.

Here is the (possible) bug:
 /* first part, some error-treating code deleted for clarity and brevity */
    num = GET_UShort();
    for ( n = 0; n < num; n++ )
    {
      post20->glyphNameIndex[n] = GET_UShort();
    }

Here, a first table is filled with with the indexname values.

Then:
/* Again, some code for allocation and initialization has been deleted */
    /* Now we can read the glyph names which are stored in */
    /* Pascal string format.                               */
    for ( n = 0; n < num; n++ )
    { 
      nameindex = post20->glyphNameIndex[n];

      if ( nameindex < 258 )
        ;                               /* default Mac glyph, do nothing */
      else
      { 
        len = GET_Byte();

        if ( ALLOC_ARRAY( post20->glyphNames[nameindex - 258],
                          len + 1, Char ) ||
             FILE_Read( post20->glyphNames[nameindex - 258], len ) )
          goto Fail1;

        /* we make a C string */
        post20->glyphNames[nameindex - 258][len] = '\0';
      }
    }


Thus, the glyph nameindex-258 takes the value of the current name.

This is wrong.

Here is why:

Suppose we have a font with all standard glyphs, and three more glyphs
/foo, /mud and /bar.

The table could look like the following (the first 261 is the number of
names):
<261><0><1>...<257><259><260><258> followed by the pascal strings:
<3>foo<3>mud<3>bar

In the current code, glyph #259 would be called /foo, glyph #260 would
be called /mud and glyph #258 would be called /bar. However, according
to the TT reference manual (@developers.apple.com) and according to pdftex,
the correct interpretation should be:
glyph #258 has name index 259, therefore has name mud
glyph #259 has name index 260, therefore has name bar
glyph #260 has name index 258, therefore has name foo.

Quoting the refman:
"Format 2 is used for fonts that contain some glyphs not in the standard
set or whose glyph ordering is non-standard. The glyph name index array
in this subtable maps the glyphs in this font to a name index. If the
name index is between 0 and 257, treat the name index as a glyph index
in the Macintosh standard order. If the name index is between 258 and
32767, then subtract 258 and use that to index into the list of Pascal
strings at the end of the table. In this manner a font may map some of
its glyphs to the standard glyph names, and some to its own names."

pdftex uses this.

Now the long story:

I am trying to understand fully how to transfer TTF fonts in TeX and
pdfTeX. There are various bugs along the road, and one of them was the
following: using the perfectly well known Impact font (from Monotype
foundry, distributed for free by Microsoft), I found that the Euro glyph
was mapped by ttf2tfm to some other char. This could be seen when making
a box around the glyph (the other char was "undercommaaccent" I
believe). Using gfontview (which, in turn, uses freetype I think), I saw
that Euro was actually the name of the glyph (undercommaaccent). But the
Euro glyph (the real one) did also exist (I know that, I typed it in
Winword).

Using ttf2pk (ie latex + dvips), my sample file displayed an
undercommaccent when using the PSName=Only option, when using the
\texteuro command (which, in turned, called the symbol called Euro).

Using pdftex with ttf2pk metrics, the metrics were still those of the
undercomma accent, but the picture was that of the Euro. So Acrobat
reader knew something more, that I didn't know.

So I browsed through the source code of pdftex, ttf2pk, libfreetype, and
apple's refman. This is my conclusion. But, I am quite new to this. So I
would like some advice, before submitting (somewhere) a bug report.

Thanks again,

-- 
Jean-Christophe Dubacq