- From: Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com>
- Date: Tue, 19 Jan 2016 21:29:22 +0000
- To: Roderick Sheeter <rsheeter@google.com>
- CC: "w3c-webfonts-wg (public-webfonts-wg@w3.org)" <public-webfonts-wg@w3.org>
- Message-ID: <7669d94602bf48d9bf84f5dc3eb5fe1d@wob-maildb-04.agfamonotype.org>
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] Sent: Tuesday, January 19, 2016 4:05 PM To: Levantovsky, Vladimir Cc: w3c-webfonts-wg (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 Tuesday, 19 January 2016 21:29:50 UTC