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> 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]
>> 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
>>
>>
>
>