Custom Parameter for 'post' table type 2

Hi all,

Are there a way to generate post table type 2 instead of type 3?

We are using some tools that require a post table type 2.

Thanks in advance,

Nicolás

I just generated a TTF from Glyphs 2 and the font contains a post table type 2.

There is something odd, the last glyph is an additional glyph (not contained in the .glyphs file) and it has the name of .ttfautohint.

What do you think is happening?

Best,

Nicolás

If you autohint a TTF in Glyphs, it will use ttfautohint, an open source autohinter. ttfautohint always adds this extra glyph if you use it on a font, although I’m not sure why. It also adds an entry in the name table by default, although it’s possible to suppress that. (All of this is true if you run ttfautohint from the command line or any other way as well.)

A little detail on that added .ttfautohint glyph:
http://www.freetype.org/ttfautohint/doc/ttfautohint.html#the-.ttfautohint-glyph

@MarkSimonson and @composerjk, Thanks very much for your clarifications. Those have been very helpful.
Best,
Nicolás

I am returning to this post in order to understand why CFF-OTFs are generated with post tables type 3. Looking at the tables I could think that because a CFF-OTF has the postscript glyph name inside the CFF table, there is not reason to duplicate that information in a post table Type 2. But I would like to know if there is a way to trigger Glyphs.app to generate a CFF-OTF font with a post table type 2. Some (in fact almost all) of the tools that I am using looks inside post tables for postscript glyph names.

Something that I found in the Apple True-Type reference manual says:

Apple recommends against using ‘post’ table format 3 under most circumstances, as it can create problems with some printer drivers and PDF documents [of our tools]. The savings in disk space usually does not justify the potential loss in functionality.

I would like to know what do you think.

Best,

I’ll have a look.

The reference is in conflict with the OpenType spec or is referring to TT based fonts:

OpenType fonts with CFF data use Version 3.0 only.

Hi @GeorgSeifert,

Definitely the reference is referring to TT based fonts.

I have an issue exporting TTF, that is the reason why I am not exporting directly TTF from Glyphs.app. The issue is that some glyphs lose their advance width.

As you can see in the attaches images, a side by side of the hmtx table, to the left is the TTF and to the right is the OTF (both generated from Glyphs.app (same file that I have sent you before)

What I have been doing to patch this is generating a OTF, then I dump the hmtx of that OTF and fuse it into a new generated TTF, that is in order to fix those glyphs. But the problem is that the second glyphs in the OTF is a space character (glyphRefID="1" advance="261"), while in TTF is a NULL (glyphRefID="1" advance="0"). And we know that NULL cannot have advance width. The following image illustrate that.

What I would like to have is a way to generate a OTF without changing the position of the Space character. As you can see in the file that I sent you before, the TTF is generated according to the glyph order custom parameter, while the OTF changes the position of the space, but again the TTF loses the integrity of the glyphs metrics.

What are those glyphs? I fixed a few spacing in ttf related problems in the latest beta version (781). Maybe that solves your problem already. It had to do with some long glyph names.

And the next time you come across a problem like this, write me an email about it instead of trying to find a workaround.