RE: Redundant and unnecessary data (was): Transforming hmtx table

Hi John, all,

With my WG chair hat off, just as a regular group participant expressing my personal opinion:

I think we need to clearly distinguish two cases:
1) taking a font file as an input into WOFF2 compressor squeezing as much redundancy out of it and, on the other end, having a decompressor produce a fully functional and 100% equivalent (although not binary matching) font file to use, and
2) taking a general purpose font file and transforming it into a different, stripped down version of the font file where certain info that was deemed unnecessary for webfont use case had been stripped (thus producing a font file that I would consider to be an input font file for WOFF2).

I believe that Adam's proposal describes option 2) preprocessing step, where a font file would be optimized for web use but remains for all intent and purposes a generic input font file as far as WOFF2 is concerned. I would argue that 2) is outside of WOFF2 scope since any font vendor can pre-process and optimize their fonts for web use as part of the font production process (we certainly do it at Monotype). Yet, this is not for the WOFF2 encoder to decide what portions of the font data can be lost and never need to be recovered - while the WOFF2 process is not going to produce a binary match we do strive to preserve every bit of font functionality presented to WOFF2 as input.

Thank you,
Vlad


-----Original Message-----
From: John Hudson [mailto:john@tiro.ca] 
Sent: Friday, April 24, 2015 2:53 PM
To: David Kuettel; Levantovsky, Vladimir
Cc: Behdad Esfahbod; WOFF Working Group
Subject: Redundant and unnecessary data (was): Transforming hmtx table

On 24/04/15 11:25, David Kuettel wrote:

> There is a section on the related hdmx table, which Raph recommended 
> either just compressing or stripping altogether.

I believe this is getting into the area of pre-Brotli optimisation recommendations, along the lines that Adam Twardoch suggested during the Portland meeting in 2013. There is a lot of data in a typical sfnt font that is either redundant or unnecessary for webfont environments. It makes sense to strip such data, but probably not to do so at the MTX-like Brotli processing stage (unless we were to define two different modes of Brotli compression: normal and super).

I still like Adam's idea of something like the approach taken to PDF document standards: definitions of sfnt data sets for different purposes, beginning with a webfont optimisation recommendation. As I recall, this was judged outside the existing mandate of the Webfonts WG, but the informal interest group approach doesn't seem to have gained any traction.

Ideas?


JH

Received on Friday, 24 April 2015 19:41:46 UTC