Re: Minutes, 3 Sept 2014 webfonts call

With regard to 255Uint16, current implementation appears to produce
consistent results and use the minimum number of bytes. For example, we
would produce [254, 0] for 506 (from spec "For example, the value 506 can
be encoded as [255, 203], [254, 0], and [253, 1, 250]").

It's not entirely obvious to me that we need to dictate which is the
correct way to encode a given value. If someone figures out a clever hack
where one encoding or another compresses better they should be able to use
it. I do think we should require consistent encoding and suggest use of a
shorter encoding. Perhaps we might change:

An encoder may produce any of these, and a decoder must accept them all,
although encoders should choose shorter encodings, and should be consistent
in choice of encoding for the same value, as this will tend to compress
better.

To something like:

An encoder may produce any of these, and a decoder must accept them all. An
encoder SHOULD choose shorter encoding and MUST be consistent in encoding
for the same value, as this will tend to compress better.



On Wed, Sep 3, 2014 at 2:20 PM, Roderick Sheeter <rsheeter@google.com>
wrote:

> For minimal benefit in following a recommendation (vs a requirement) of
> the OT Spec SHOULD seems perhaps more appropriate than MUST.
>
>
> On Wed, Sep 3, 2014 at 1:36 PM, David Kuettel <kuettel@google.com> wrote:
>
>> On Wed, Sep 3, 2014 at 10:51 AM, John Hudson <tiro@tiro.com> wrote:
>>
>>> Apologies for missing today's call.
>>>
>>>
>>>      sergeym: maybe we should require a decoder to put tables in the
>>>>     order that is recommended by the OT spec, regardless of what
>>>>     order it was in the original input file.
>>>>
>>>
>>> This is what I was going to suggest too. I wonder if it is a SHOULD or
>>> MUST situation, though? As I understand it, the performance benefit is now
>>> considered minimal, although I'd love to see some comparative data.
>>
>>
>> This is one change where I don't think we would be able to easily measure
>> the performance benefit, although Sergey might have some thoughts on how
>> to.  Agreed that the benefit would likely be minimal, esp. in the common
>> case.  For consistency / best practices reasons however, the proposal seems
>> good.
>>
>>>
>>>
>>> JH
>>>
>>>
>>
>