RE: Agenda+ topic for WG call on May 18

Thank you Garret,

 

I’ve been going rounds in WOFF2 spec trying to find a hint as to why the transformed ‘glyf’ table has its version number defined as Fixed (and why it’s there) – so far, no mentioning of it anywhere other than in the format description itself. Any recollections as to why we defined it that way?

 

I also realized that the use of “version” is overloaded in the WOFF2 – we have transform version defined for every table as part of the table directory entry, and then most of the transformed tables do not have their own versions defined, the ‘glyf’ table is the only exception. 

 

Would it make sense to redefine this field to a Uint16 version number and Uint16 bit field where we can use one bit as a flag indicating the presence of the additional data structure? In general, I’d prefer not to rely on version numbers to define the data structures, I’d rather have a dedicated flag to indicate that a particular flag6Bitmap array is present.

 

Thanks,

Vlad

 

 

From: Garret Rieger [mailto:grieger@google.com] 
Sent: Monday, May 17, 2021 7:34 PM
To: Myles C. Maxfield <mmaxfield@apple.com>
Cc: Vladimir Levantovsky <vladimir.levantovsky@gmail.com>; Web Fonts Working Group <public-webfonts-wg@w3.org>
Subject: Re: Agenda+ topic for WG call on May 18

 

Another option would be to use the "version" field on the transformed glyf table to indicate the presence of additional streams (when version = 1). I checked the current woff2 decoder implementation and it currently ignores the value of version, so changing that could be backwards compatible (if the other decoder implementations also ignore it).

 

On Fri, May 14, 2021 at 8:36 PM Myles C. Maxfield <mmaxfield@apple.com <mailto:mmaxfield@apple.com> > wrote:

I’m actually off on Tuesday, so I won’t be able to make this call.

 

—Myles





On May 13, 2021, at 11:13 AM, Vladimir Levantovsky <vladimir.levantovsky@gmail.com <mailto:vladimir.levantovsky@gmail.com> > wrote:

 

Topic: WOFF2 handling of simple glyph flags (See  <https://github.com/google/woff2/issues/117> https://github.com/google/woff2/issues/117 for details.)

 

Background: 

Simple glyph flags define the format of x/y coordinate vectors for each point of the glyph outline. In WOFF2, the pre-processing step converts both the flags and the coordinates themselves into different data streams. Six different flags (bits 0-5) can be set to define on/off-curve point and the format for each set of point coordinates, flags can be shared among multiple point coordinates. 

 

The bit 6 flag (OVERLAP_SIMPLE) is different, it can only be set once on the first flag of the glyph. If set, it indicates that contours of the glyph _may_ overlap. The OpenType spec doesn’t require this flag be set, and some (but not all) rasterizers would ignore this bit. Bit7 is reserved / unused. (See description of simple glyph flags for details:  <https://docs.microsoft.com/en-us/typography/opentype/spec/glyf> https://docs.microsoft.com/en-us/typography/opentype/spec/glyf)

 

Some years ago (in 2011-2014 timeframe, I wasn’t able to find any specific references to the discussion about flags) a decision was made that since flag bit6 is not required and bit 7 is reserved, they can simply be omitted when the source data is encoded, and set to ‘0’ upon reconstruction of glyph data. Apparently, this has caused the loss of data for flag bit 6 in some fonts that have glyphs with overlapping contours where this bit 6 is set, and it’s an issue for some rasterizers that still rely on flag bit 6 setting to deal with contour overlaps.

 

Proposed solution:

WOFF2Header ( <https://www.w3.org/TR/WOFF2/#woff20Header> https://www.w3.org/TR/WOFF2/#woff20Header) has Uint16 field reserved. One of these 16 bits can be redefined to be used as a flag indicating presence of the new data stream, which can be used to encode overlap flag (bit 6) values.

 

Since bit 6 flag can only be set once per glyph, a new numGlyphs-long bit array can be defined and appended in the end of the WOFF2 transformed ‘glyf’ table ( <https://www.w3.org/TR/WOFF2/#glyf_table_format> https://www.w3.org/TR/WOFF2/#glyf_table_format) to encode overlap flag values for simple glyphs. (We are in good shape for composite glyph flags since they are part of the compositeStream[]). I believe this change would be 100% backward compatible – legacy WOFF2 decoders would not care about reserved bit values and would not expect/read an additional bit array in the end of the table.

 

Spec changes:

Due to the fact that this would be a minor non-breaking specification change that is clearly needed to fix a bug / design flaw, I believe we can utilize an errata process ( <https://www.w3.org/2020/Process-20200915/#errata> https://www.w3.org/2020/Process-20200915/#errata) for the purpose of revising a Recommendation introducing substantive changes ( <https://www.w3.org/2020/Process-20200915/#revised-rec-substantive> https://www.w3.org/2020/Process-20200915/#revised-rec-substantive). Once spec changes are drafted, we’d issue a Call for Review of the Proposed Changes ( <https://www.w3.org/2020/Process-20200915/#last-call-review> https://www.w3.org/2020/Process-20200915/#last-call-review) that can be rolled into the existing WOFF2 Recommendation upon approval.

 

Thank you,

Vlad