[MPEG-OTSPEC] Some thoughts on the "under consideration" proposals

[Takaaki Fuji 藤 貴亮]

Hi all,

Having a small discussion at CITPC in Japan, I had a chance to have a look at the Boring Expansion proposal. Here's my quick memo on it:

- Everyone expects that he/she can allocate a sufficiently-sized array with maxp.numGlyphs/hhea.numberOfHMetrics, but they suddenly becomes unreliable for being capped to 16-bit in the proposal. I don't personally care if the spec says so and most of the clients start to follow, but the workaround to parse hmtx/vmtx/VORG tables over the boundaries looks trickier than just bumping up the version of each table. In what way is the change 'boring' – any benefits on compatibility? And the spec needs a good way to reference the number of glyphs in a font without mentioning maxp.numGlyphs :)

- One of the motivations to prefer CFF/CFF2 in CJK fonts should be the subroutinization, which should reduce the footprint even for the non-componentized fonts in a lossless manner. The so-called smart component approach is not always applicable depending on how our masters are designed. I expect the cubic 'glyf' tables should become larger than those of 'CFF'/'CFF2' if naively translated – is there any analysis on the storage efficiency between the two? The container-level compressions like WOFF2 should give a solid compaction but it's not the format which can be mapped straight onto a memory.

- As far as I see when the dummy VORG table is supplied in a OpenType/CFF font, the current version of the spec states that it's completely discretional whether to shift the y coordinate of each glyph based solely on the 'vmtx' table. It totally makes sense that Harfbuzz doesn't, but on the other hand OTMaster does, according to my observation. I don't believe such font would exist in the wild but maybe we can remove this ambiguity to make them consistent.

I might not be fully following the whole discussion happened so sorry it may sound redundant. My honest intention here is not to nitpick the proposal but just to say kudos; my daily job is about building CJK fonts that conform to the spec and making sure they would work on our target platforms, rather than implementing a text layout stack. So it's so nice to hear the 64K barrier go, and we hope the resulted spec will have no conflicts so that our 'older' fonts keep working and both will coexist as spec-compliant fonts. Thanks!

Sincerely,

Takaaki Fuji
Morisawa Inc.
tfuji at morisawa.co.jo <mailto:tfuji at morisawa.co.jo>