Re: Updated WOFF2 spec is available for review

On 19/1/16 21:42, Roderick Sheeter wrote:
> My mistake on glyf "n"; I read your email and assumed n was current not
> next. If n is next then all is well. If we could manage to word it based
> on loca[n] == loca[n+1] it would match up with the otspec wording for
> loca, which might be nice.
>
> My understanding after asking around a bit is that lsb for an empty
> glyph doesn't do anything and it is thus harmless to zero out. My

Agreed. For an empty glyph, the whole concept of lsb is meaningless.

> thought is that ignoring it gives better odds we can apply hmtx
> optimizations while requiring it be 0 gives a non-obvious way for a font
> to avoid them, most likely unintentionally.
>
> Harmless to zero out /probably /also applies to the degenerate non-empty
> 0 contour glyph.

That seems likely. Offhand, I can't think of a way that anything can 
depend on the lsb of a zero-contour glyph. I suppose such a glyph can 
have instructions, but I don't recall any way that the truetype 
instructions would be able to read the lsb value and then use it to 
influence something else, for example.....

I don't have a strong view on whether we should actually specify such 
zeroing, though. ISTM that if a font developer is creating fonts with 
features such as non-zero LSB values for empty glyphs and/or degenerate 
(zero-contour) non-empty 'glyf' records, it's not necessarily our job to 
optimize things for them.

JK

PS: Vlad -- my apologies for today, but I don't expect to be able to 
make the telcon -- I have to be out for a while right in the middle of 
that timeslot. :(

>
> Cheers, Rod S
>
> On Tue, Jan 19, 2016 at 1:29 PM, Levantovsky, Vladimir
> <Vladimir.Levantovsky@monotype.com
> <mailto:Vladimir.Levantovsky@monotype.com>> wrote:
>
>     With “n” being a glyph record count – the handling of a loca table
>     entries depends on whether you increment the count first and then
>     create a loca table entry or vice versa. ____
>
>     __ __
>
>     In case when the last valid loca entry points to the end of the
>     current glyph records (which IMO it should after the last glyph
>     record is properly reconstructed):____
>
>     The current description for empty glyph reconstruction says:____
>
>     __1)__Increment the count (i.e. “n” will point to the next entry);____
>
>     __2)__Make a new loca entry by assigning the next one the same value
>     as the previous one, i.e. loca[n] = loca[n-1].____
>
>     Am I missing something?____
>
>     __ __
>
>     For hmtx – it’s possible that some empty glyphs (e.g. <space>) would
>     have non-zero advanceWidth but I am not sure about lsb values. Plus,
>     if we don’t check the lsb of the empty glyph at all, how do we know
>     that reconstruction should always produce lsb = 0? I seemed logical
>     that since the empty glyph always has an implied xMin=0 we would
>     check this condition to validate the hmtx transform condition but I
>     am open to discussing this and can be convinced otherwise.____
>
>     __ __
>
>     Thanks,____
>
>     Vlad____
>
>     __ __
>
>     __ __
>
>     *From:*Roderick Sheeter [mailto:rsheeter@google.com
>     <mailto:rsheeter@google.com>]
>     *Sent:* Tuesday, January 19, 2016 4:05 PM
>     *To:* Levantovsky, Vladimir
>     *Cc:* w3c-webfonts-wg (public-webfonts-wg@w3.org
>     <mailto:public-webfonts-wg@w3.org>)
>     *Subject:* Re: Updated WOFF2 spec is available for review____
>
>     __ __
>
>     For empty glyphs, it should probably point to the /next/ record or
>     take the value numGlyphs+1 if this is the last glyph. Adjusting n-1
>     to have the same offset as n would denote n-1 as empty rather than
>     marking n empty.____
>
>     __ __
>
>     For hmtx eligibility, I would prefer we don't check it's lsb of an
>     empty glyph at all (instead of requiring 0). That is, write
>     something like:  "...MUST check that leftSideBearing values match
>     the xMin values of the glyph bounding box for every *non-empty
>     *glyph in a font"____
>
>     __ __
>
>     We might also consider ignoring the lsb value for the degenerate
>     non-empty glyph with numContours == 0 as it's basically a poor
>     encoding of an empty glyph as far as I can tell.____
>
>     __ __
>
>     Cheers, Rod S____
>
>     __ __
>
>     On Tue, Jan 19, 2016 at 12:48 PM, Levantovsky, Vladimir
>     <Vladimir.Levantovsky@monotype.com
>     <mailto:Vladimir.Levantovsky@monotype.com>> wrote:____
>
>     Folks,____
>
>     ____
>
>     Per action 194 I made the following changes in the WOFF2 spec [1]:____
>
>     -Handling of the empty glyph records in glyph table transform:
>     instead of requiring a decoder to create an empty glyph record with
>     no contours and zeroed-out bbox we should rather handle this by
>     simply omitting the glyph record and creating a new entry in the
>     loca table with the offset pointing to the previously created [last]
>     glyph record so that loca[n] = loca[n-1];____
>
>     -Added new conformance case for AT [2]: mustClearEmptyBBox – needs
>     test description!____
>
>     -Eliminated the DC conformance case mustCalculateEmptyBBox;____
>
>     -Changed UA [3] conformance case mustRejectNonEmptyBBox – now set to
>     unconditionally reject a font that has explicitly encoded bbox of an
>     empty glyph. The existing test description seem to be fine, needs
>     review!____
>
>     -Special case handling for empty glyph records in hmtx transform
>     (action 194): in order to confirm hmtx transform eligibility check
>     that lsb of an empty glyph is equal to zero.____
>
>     ____
>
>     Let’s review and discuss it tomorrow during our telcon.____
>
>     ____
>
>     Thank you,____
>
>     Vlad____
>
>     ____
>
>     [1] http://dev.w3.org/webfonts/WOFF2/spec/____
>
>     [2]
>     https://www.w3.org/Fonts/WG/wiki/TestPlan20-AuthoringTool#Testable_Assertions____
>
>     [3]
>     https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustRejectNonEmptyBBox____
>
>     ____
>
>     __ __
>
>

Received on Wednesday, 20 January 2016 14:38:41 UTC