Re: WOFF-ACTION-176: Test hmtx transformation over google fonts corpus (how many lsb == x-min for all glyfs, what savings)

Jonathan and others,

This has been a concern for me, and it also affects all of the proposed pre-processing of the CFF table. As long as what is thrown out, to reduce size during transmission, is restored upon receiving, I don't see a problem. If something is removed and not restored, there is a non-zero chance that something, somewhere, will break due to a dependency. A good example for dependency on CFF data may be Adobe Acrobat Distiller, but I'd need an example font to use.

Anyway, and pardon the non-hmtx topic, my understanding from this week's meeting is that Behdad has proposed that 1) the CFF's character set data be removed; 2) horizontal advances be removed; and 3) "endchar" be removed. I also understand, based on testing that took place after the meeting, that the benefit of #3 doesn't seem worth the complexity. I am still concerned about #1 and #2 if this information is not restored on the receiving end. I'd also like more clarification about how #1 affects name- and CID-keyed fonts, because these are the two flavors of CFF.

Regards...

-- Ken

> On May 22, 2015, at 12:58 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
> 
> On 21/5/15 20:30, Behdad Esfahbod wrote:
> 
>> This can also be applied to CFF.  The side-bearings are unused for CFF
>> fonts, so just throwing them away is fine.
> 
> Do we know for sure that no software makes use of the sidebearings in CFF fonts in any way?
> 
> If that's the case, I suppose a decoder -- or indeed a font-creation tool -- could simply set LSB to zero for every glyph in a CFF font. But this sounds like something that would need to be checked in depth.
> 
> JK
> 
> 

Received on Friday, 22 May 2015 12:41:39 UTC