v2 vs v3 'post' table?

Thomas Phinney
Thomas Phinney Posts: 2,896
edited January 2021 in Font Technology
One question that I have heard kicked around is what utility there is, for OpenType fonts with TrueType outlines, to having the old v2 'post' table (which has glyph names) vs a v3 'post' table that omits the glyph names. It is more of a placeholder.

I’ve certainly often talked about the limited (but real) utility of proper glyph names at length in the past. The main use case I know of comes in with CFF (not CFF2) workflows where a print stream is being processed to PDF, the original font is unavailable at the time of processing, and the PDF creator is trying to re-create a text stream at that point—without the encoding available, just glyph names (and GIDs, but they are not much use by themselves). So there are a whole bunch of corner cases in play at once there. But what about glyph names and TrueType outlines?

Well, besides “normal” glyphs that have an encoding, there are glyphs that are unencoded, whose meaning can be backtracked only if one has access to the GSUB table or the text stream. So the glyph name can be a useful shorthand. It would be indispensable in any situation where one is missing the text stream, and has the glyph data but not the GSUB—but when would that reasonably happen with TTF, if at all? (I don’t *think* it happens with print streams, but my knowledge of this is not at all current, plus my recollection could be wrong.)

And are there any other reasons to keep a v2 'post' table around in TTF? Or should it just be dropped to save one or two tens of KB of data?
Tagged:

Comments

  • Mateusz Karpow
    Mateusz Karpow Posts: 6
    edited January 2021
    2 years ago (haven’t tested since, though), one reason to keep it would have been a bug in Apple’s code: pt. 7 here. We decided the very substantial saving warrants going with version 3, though. Sometimes, I’ve spent hours, or days, trying to shave eg. 250 bytes, so this kind of saving was a no-brainer.
  • Aaron Bell
    Aaron Bell Posts: 93
    For a time Microsoft wanted to ship all fonts as post table v3 but I think they’ve backtracked from that recently.

    As far as I can tell, post table v3 is really only useful for the file size savings, but it comes at a cost of making the font file harder to work with. I suppose as a final post-production step it might be fine...

    With the exception of CJK, where the file size saving of p3 can be quite substantial (like using CID), I don’t really see the point, TBH.
  • John Hudson
    John Hudson Posts: 3,227
    I thought the Acrobat name parsing worked the same way for post table glyph names in embedded TTFs as for CFF?
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    edited January 2021
    Yes, but...
    With TTF, the cmap is guaranteed to be always there.
    With CFF, in some workflows, the original cmap can be lost.
    So, the “cmap is missing” case is specific to CFF.

    But aside from that, yes.

    I have no idea what happens with CFF2 and how that might vary by workflow. I can imagine some very surprising behaviors (like printer drivers adding glyph names in the print stream!).
  • John Hudson
    John Hudson Posts: 3,227
    But it isn’t just presence of the cmap that matters, because not all glyphs in the PDF strings are going to be encoded. So name parsing still matters, it’s just that in the TTF it can rely on the cmap for some glyphs rather than always relying on the name mapping.

    CFF2 is closer to TTF: there are no names in the CFF2 table, but the post table will most commonly be format 2, i.e. with names. Of course, it will be possible to make a format 3 post table in a CFF2 font, just as it is possible to make a TTF that way.

Categories