RE: Updated WOFF2 spec is available for review

Folks,

As a follow up to our telcon discussion, the updated WOFF2 spec now includes the new line describing most recent changes to the spec.
I believe the current version is ready for transition to CR.

Thank you all!
Vlad


-----Original Message-----
From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com] 
Sent: Wednesday, January 20, 2016 9:44 AM
To: Jonathan Kew; public-webfonts-wg@w3.org
Subject: RE: Updated WOFF2 spec is available for review

Thank you Jonathan,

The proposed modified language for hmtx transform is based on the expectation that in the vast majority of cases lsb for an empty glyph will in fact be zero. However, I'd rather check for it first and then apply the transform then make an assumption that it is ought to be zero and inadvertently modify the font in question if for whatever reason it has a non-zero lsb for an empty glyph.

Thanks,
Vlad


-----Original Message-----
From: Jonathan Kew [mailto:jfkthame@gmail.com]
Sent: Wednesday, January 20, 2016 9:38 AM
To: public-webfonts-wg@w3.org
Subject: 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_Ass

> ertions____
>
>     [3]
>     
> https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustRejectNonEmp

> tyBBox____
>
>     ____
>
>     __ __
>
>

Received on Wednesday, 20 January 2016 16:02:25 UTC