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>
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> wrote:
>
> Topic: WOFF2 handling of simple glyph flags (See
> 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)
>
> 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) 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) 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) for the purpose of
> revising a Recommendation introducing substantive changes (
> 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) that
> can be rolled into the existing WOFF2 Recommendation upon approval.
>
> Thank you,
> Vlad
>
>
>