[mpeg-OTspec] New cmap format

Martin Hosken martin_hosken at sil.org
Wed Apr 4 04:25:19 CEST 2012


Dear John,

> I'm thinking in terms of stripping fonts down to the minimum set of 
> glyphs necessary to compose Unicode text on the fly using positioning 
> features.

Rather than burdening every font shaping engine and rendering engine already in existence with a table format that people are liable to ignore for a long while yet, how about using a tool to autogenerate all your compound glyph references for you. A tool like ttfbuilder could do that after font generation. Alternatively one could write a tool to autogenerate the necessary GSUB rules to break apart the ligatures.

This seems like it's a sledge hammer (requiring everyone to change their font rendering systems and back port) to address your font creation and glyph management issues.

The reason why format 14 is useful is that it allows the easy ignoring of VSs that aren't recognised. If VSs were passed through then it would take specific handling to remove the ones that the font doesn't know about. This is doubly tricky, firstly because OpenType can't delete anything and secondly you are asking a font to delete something it knows nothing about. And thirdly, VSs are rare, latin decomposition isn't.

I agree, shaping engines should do the right thing here and decompose where a composed cmap entry is missing. In fact they should also compose decompose sequences where a composed cmap entry exists. So the issue cuts both ways. Another reason why just having a decomposing cmap isn't necessarily going to solve the problem for everyone.

Yours,
Martin



More information about the mpeg-otspec mailing list