Re: hmtx optimization over the Google Fonts collection

Yup, will do. Fingers crossed they can work further magic for us :D

However, I would think this expected behavior as it's hard to predict how
well brotli can compress a given input.


On Wed, Jan 20, 2016 at 9:27 AM, Behdad Esfahbod <behdad@google.com> wrote:

> Right... But the ones, say, growing 2k in size are interesting.  Can you
> ping Brotli people so they are at least aware of this?
>
> On Wed, Jan 20, 2016 at 6:13 PM, Roderick Sheeter <rsheeter@google.com>
> wrote:
>
>> I think it's because the result is can be an input buffer that is less
>> friendly to brotli.
>>
>> To give an example, lets take ArbutusSlab-Regular.ttf. It's hmtx barely
>> saves anything (Was 1734 now 1733 [bytes]). The main compression step gets
>> a smaller input but isn't able to compress it quite as well:
>>
>> hmtx_opt: Compressed 63150 to 29992.
>> not opt: Compressed 63151 to 29939.
>>
>> Plus we need an additional UIntBase128 to store the transform length.
>>
>> On Wed, Jan 20, 2016 at 9:03 AM, Behdad Esfahbod <behdad@google.com>
>> wrote:
>>
>>> Hey,
>>>
>>> I'm sure everyone wants to know: why would any font get larger?
>>>
>>> On Wed, Jan 20, 2016 at 5:45 PM, Roderick Sheeter <rsheeter@google.com>
>>> wrote:
>>>
>>>> I did a test run of hmtx optimization over the Google Fonts collection
>>>> and thought the results might be of interest. A few key results:
>>>>
>>>>    - Of 1754 font files, 80.4% (1411) got smaller, 16.4% (288) had no
>>>>    change, and 3.1% (55) got larger.
>>>>    - For fonts with savings, average was 466 bytes or 1.08% of size
>>>>       - Across all fonts, average was 368 bytes or 0.86% of size
>>>>
>>>> Cheers, Rod S.
>>>>
>>>> Per-font results can be seen in
>>>> https://docs.google.com/spreadsheets/d/1dgL-il6fIHaHJghlzXz7aM_HEtes9G7Pt7TsnlsxsGc/edit?usp=sharing
>>>> .
>>>>
>>>>
>>>>
>>>
>>
>