glyf overlap flags

Fri Apr 20 19:01:05 CEST 2018

Laurence Penny recently pointed out an issue impeding interoperability of fonts, in particular, static instance fonts generated from a variable font. The issue involves bit 6 in the simple-glyph flags of the ‘glyf’ table. MacOS uses that bit in a particular way, though it’s not clearly documented by Apple: Per Apple’s ‘glyf’ spec<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Ffonts%2FTrueType-Reference-Manual%2FRM06%2FChap6glyf.html&data=02%7C01%7Cpetercon%40microsoft.com%7C1489fdd1df1545faac7a08d5a645d836%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597741274402475&sdata=FHamrel3LlvkbkixYUpC%2BdKIhcvdGM5%2BiAwsbiRhWfQ%3D&reserved=0>, bit 6 is reserved. However, the Intro page for Apple’s spec<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Ffonts%2FTrueType-Reference-Manual%2FRM06%2FChap6AATIntro.html&data=02%7C01%7Cpetercon%40microsoft.com%7C1489fdd1df1545faac7a08d5a645d836%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597741274412488&sdata=Hv%2BR9RZe6BWGQmWf49s%2BKiDEgXB3K6rbXCaOv60VjoQ%3D&reserved=0> does describe bit 6 being used to enable non-zero-fill rasterization.

This is something that Adam Twardoch described a couple of years ago:

https://github.com/twardoch/test-fonts/tree/master/varia/160413-EvenOddTT<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftwardoch%2Ftest-fonts%2Ftree%2Fmaster%2Fvaria%2F160413-EvenOddTT&data=02%7C01%7Cpetercon%40microsoft.com%7C1489fdd1df1545faac7a08d5a645d836%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597741274422501&sdata=wTMYcqw5Wwkh1JXok7WJSwkiMjJukz8fw9KztumRYOE%3D&reserved=0>

The OT and OFF specs currently are consistent with Apple’s ‘glyf’ documentation, saying that bit 6 is reserved. Some libraries and tools may be following that spec. OT Sanitizer appears to be one particular case of this: it rejects fonts if bit 6 is set, which is not surprising given that the OT spec says the bit is reserved and must be set to 0. As a result, fonts that set bit 6 are rejected by browsers such as Firefox and Chrome that integrate OTS. But bit 6 might need to be set in some fonts in order for them to work on MacOS. This was discussed some months back in the ots project on GitHub, and the consensus was that this should first be addressed as a spec bug.

https://github.com/khaledhosny/ots/issues/146<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkhaledhosny%2Fots%2Fissues%2F146&data=02%7C01%7Cpetercon%40microsoft.com%7C1489fdd1df1545faac7a08d5a645d836%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597741274432510&sdata=lkqKMBrAEE9C1rODq783N5kKgWIBUa3UcZKm7bSi4Oc%3D&reserved=0>

Accordingly, I have drafted this revision for the 'glyf' spec for OT 1.8.3, and suggest it for OFF:

Simple Glyph Flags
Mask

Name

Description

...

0x40

OVERLAP_SIMPLE

Bit 6: If set, contours in the glyph description may overlap. Use of this flag is not required in OpenType — that is, it is valid to have contours overlap without having this flag set. It may affect behaviors in some platforms, however. (See Apple’s specification<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Ffonts%2FTrueType-Reference-Manual%2FRM06%2FChap6AATIntro.html&data=02%7C01%7Cpetercon%40microsoft.com%7C6e33be6d40ee4e75827a08d5a63bfd96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597699014806755&sdata=XshxBKP0NlvkSx64TZweBj7T4kSZ%2FYCv7eugB5ga%2F0g%3D&reserved=0> for details regarding behavior in Apple platforms.) When used, it must be set on the first flag byte for the glyph. See additional details below.

0x80

Reserved

Bit 7 is reserved: set to zero.

A non-zero-fill algorithm is needed to avoid dropouts when contours overlap. This can be particularly relevant for variable fonts, which often make use of overlapping contours. The OVERLAP_SIMPLE flag is used by some rasterizer implementations to ensure that a non-zero-fill algorithm is used rather than an even-odd-fill algorithm. Note that some implementations might use this flag specifically in non-variable fonts, but not in variable fonts. Implementations that always use a non-zero-fill algorithm will ignore this flag. This flag can be used in order to provide broad interoperability of fonts — particularly non-variable fonts — when glyphs have overlapping contours. Tools that generate static-font data for a specific instance of a variable font should either set this flag when contours in the derived glyph data are overlapping, or else should merge contours to remove overlap of separate contours.

Note: The OVERLAP_COMPOUND flag, described below, has a similar purpose in relation to composite glyphs. The same considerations described for the OVERLAP_SIMPLE flag also apply to the OVERLAP_COMPOUND flag.

And later:

Composite Glyph Flags
Mask

Name

Description

...

0x0400

OVERLAP_COMPOUND

Bit 10: If set, the components of the compound glyph overlap. Use of this flag is not required in OpenType — that is, it is valid to have components overlap without having this flag set. It may affect behaviors in some platforms, however. (See Apple’s specification<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Ffonts%2FTrueType-Reference-Manual%2FRM06%2FChap6glyf.html&data=02%7C01%7Cpetercon%40microsoft.com%7C1489fdd1df1545faac7a08d5a645d836%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636597741274442518&sdata=tfjYTNh8WFP2xpO2U%2BnAyeXWC5VgSnbcVzZ%2BMqf1QpM%3D&reserved=0> for details regarding behavior in Apple platforms.) When used, it must be set on the flag word for the first component. See additional remarks, above, for the similar OVERLAP_SIMPLE flag used in simple-glyph descriptions.

...

Comments are welcome.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20180420/879f7df3/attachment.html>