RE: Question about instructionLength of simple glyphs

Hi Rod, all,

Regarding:

  *   Spell out what to do for 0 with equal weight to the other options instead of hiding it in step 1
     *   Add "Decoding an empty glyph" heading of equal weight to the other Decoding of... headings

(reproducing part of my previous email on this subject), we have multiple options to consider:


Empty glyphs in an input font file have xmin, ymin, xmax, ymax values as all zeros.

1) an encoder can see an empty glyph and decide that since there are no outlines and no source to compute bounding box info - it needs to be explicitly encoded as all zeros (which is acceptable) and would set the bonding box bit with all zeros as encoded values;

2) an encoder can see an empty glyph and decide that because no outlines = no ink = bounding box is [0,0,0,0], this can be inferred from an empty glyph (so it will clear the bounding box bit telling the decoder to compute an empty bounding box (which is also acceptable);

3) an encoder generates a glyph entry for an empty glyph with bounding box bit set and non-zero values encoded - this is probably the only condition that could be treated as error, although I am not sure if it will have any effect once the font is used to render a text. Should we catch it as error condition and invalidate the woff2 file that caused it?

Since both first and second options are plausible scenarios that cause no harm, I am not sure if we need to allow both or choose a single one (e.g. option 2) and mandate the behavior for all compliant implementations. IMO, I would strongly recommend (as in “SHOULD”) that encoders produce empty glyphs with implicit [0,0,0,0] bounding box info (as in option 2) but allow decoders to support either option 1 or 2 since both are harmless, option 1 is a bit redundant but would still produce a usable output font file. So, a question to the WG – should we be permissive here, or do we need prescribe a specific behavior and enforce it?

Option 3 is an error for which we can either invalidate the whole woff2 file or mandate the decoder to fix it (i.e. to zero out all bounding box values when decoding an empty glyph) – which one of these two outcomes you guys would prefer?

Thank you,
Vlad


From: Roderick Sheeter [mailto:rsheeter@google.com]
Sent: Friday, March 27, 2015 4:05 PM
To: Jonathan Kew
Cc: Levantovsky, Vladimir; Khaled Hosny; WebFonts WG
Subject: Re: Question about instructionLength of simple glyphs

Having read the relevant section, a few formatting tweaks would have made it easier to read (at least for me):

  *   There is no heading for the overall reconstruction process; my eye says that "Decoding of Simple Glyphs" is where this section starts but I actually have to backtrack to find step 1

     *   Add a heading of at least equal weight as "Decoding of XXX Glyphs" above "The reconstruction proces..."; "Reconstructing a Glyph" perhaps?

  *   Spell out what to do for 0 with equal weight to the other options instead of hiding it in step 1

     *   Add "Decoding an empty glyph" heading of equal weight to the other Decoding of... headings

  *   The first sentence of "Decoding of Composite Glyphs" specifies the nContour value but "Decoding of Simple Glyphs" doesn't; would be nice if they were consistent.
YMMV

On Fri, Mar 27, 2015 at 12:56 PM, Jonathan Kew <jfkthame@gmail.com<mailto:jfkthame@gmail.com>> wrote:
On 27/3/15 19:31, Levantovsky, Vladimir wrote:
Hi Khaled,

You mentioned two completely separate cases, and I believe both are sufficiently covered in the spec.
1) you have an empty glyph (numberOfContours = 0): in this case, the glyphStream will have nothing in it for this particular glyph;
2) you have a simple glyph (numberOfContours > 0): in this case the size of the instructions that need to be read from the instructionStream will be defined by the instructionLength read from the glyphStream.

I think the spec is sufficiently clear on this, is it not the case?

It seems clear enough to me, as steps 5 and 6 in the glyph reconstruction process are only performed for simple glyphs (numberOfContours > 0) and for composite glyphs (numberOfContours = -1) where FLAG_WE_HAVE_INSTRUCTIONS was set. An empty glyph is neither of these.

However, I did notice a couple of typos when reading through the "Decoding of Composite Glyphs" section:

  "A decoder MUST check for presense of the bonding box"

s/presense/presence/;  s/bonding/bounding/

Also, the last two paragraphs of section 5.1 seem somewhat contradictory. First, we read:

  "Finally, for both simple and composite glyphs, if the corresponding bit in the bounding box bit vector is set .... If the corresponding bit in the bounding box bit vector is not set, then derive the bounding box by computing..."

but the next paragraph goes on to insist that

  "A composite glyph MUST have an explicitly supplied bounding box..."

which means that the "if"s in the preceding paragraph were not really applicable to composite glyphs; in particular, the second "if" suggests that we might need to compute a bounding box (for a composite glyph), but then we go on to prohibit this.

And a further question: what happens if the bounding box bit vector says that an explicit bounding box is provided, but the glyph is empty (numberOfContours = 0)? AFAICS, this would indicate an error by the encoder, but the spec doesn't say what the decoder should do in this case.

JK

Thank you,
Vlad


-----Original Message-----
From: Khaled Hosny [mailto:khaledhosny@eglug.org<mailto:khaledhosny@eglug.org>]
Sent: Friday, March 27, 2015 3:02 PM
To: WebFonts WG
Subject: Re: Question about instructionLength of simple glyphs

On Fri, Mar 27, 2015 at 08:48:05PM +0200, Khaled Hosny wrote:
Hi all,

The “Decoding of Simple Glyphs” suggests that instructionLength is
always set for any glyph, but the reference implementation seems to
write/read it only if numberOfContours is > 0.

Reading again, I think this can be inferred from the paragraph preceding this section, but I still think an explicit note is needed.

Regards,
Khaled