- From: Ken Lunde <lunde@adobe.com>
- Date: Fri, 22 May 2015 12:41:07 +0000
- To: Jonathan Kew <jfkthame@gmail.com>
- CC: Behdad Esfahbod <behdad@google.com>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>, Cosimo Lupo <cosimo.lupo@daltonmaag.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
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