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

Thanks Cosimo, Vlad, and Jonathan.

Adding the isTransformed back and having a plan to possibly add more
transformations in the future sounds good.  Is there any way we can add
minor format version to woff2, such that the browser and server can
negotiate which transforms are supported by the decoder?  That way we can
add more transforms in woff2.1, 2.2, etc in the future...

Back to the htmx issue, I actually have another suggestion.  My grand plan
was to suggest to OpenType to introduce a new version of hmtx / vmtx that
don't have the side-bearings.  We can use metricsDataFormat in hhea / vhea
table to encode that.  Currently there's only version 0 of hmtx / vmtx
defined.  If we can quickly get buy-in from others in OpenType space, we
can go ahead and introduce a format 1 and document it and schedule it for
OpenType 1.8 whenever that goes out.  In the mean time while support is not
widespread, the woff2 decoder will synthesize a format=0 table...

This can also be applied to CFF.  The side-bearings are unused for CFF
fonts, so just throwing them away is fine.

We are interested in doing this in Android because that would save a few
hundred kilobytes, which we can then use to ship fonts for a few historical
scripts!

b

On Thu, May 21, 2015 at 7:01 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

> On Thursday, May 21, 2015 6:34 AM Jonathan Kew wrote:
> > I think you're right that Vlad's suggestion doesn't work as written,
> > as we don't have any way to determine the "actual decompressed
> > table size" to compare with the "original" size recorded in the
> directory.
>
> I guess I should've been more specific but what I actually meant was very
> similar to what you described here - comparing the actual size of the hmtx
> table recorded in the WOFF2 table directory to the 'original' size that
> could be easily calculated.
>
> > All existing WOFF2 fonts would continue to work after decoders are
> > updated to recognize this convention, because they have the
> trueHmtxLength
> > stored in the origLength field, meaning the transform has not been
> applied.
> >
> > However, my preference would be to avoid this sort of complex
> interdependency,
> > and instead bring back an 'isTransformed' flag in the
> TableDirectoryEntry flags byte.
> > This is so much simpler and cleaner -- and more extensible, if we come
> up with a
> > transform for any other table whose "true original size" may not be
> predictable
> > from other data in the font.
>
> Yes, during our discussion yesterday I quietly lamented the decision to
> get rid of the "isTransformed" flag - would have made the spec easily
> extensible, and our lives easier. When the case was made that only two
> tables would ever be subjected to transformations and the transforms would
> always be applied, it seemed reasonable to simplify things and not rely on
> the flag to indicate the obvious, but from the extensibility point of view
> having the "isTransformed" flag is definitely an advantage.
>
> Considering the fact that we already encountered a problem when the lack
> of extensibility may potentially make future technology improvements harder
> to implement - should we revisit that topic and see where we stand on this?
>
> We do have two reserved bits in the "flags" field, so modifying the
> meaning of one of them will not change the wire format of the file (in term
> of bytes served) and it may not even have an immediate effect on woff2
> fonts that are currently in circulation - existing decoders won't look for
> "isTransformed" flag and will continue to process glyf and loca tables as
> transformed tables, and future implementations (including woff2 compressed
> fonts) will be updated to comply with the new spec requirements where the
> new flag is defined.
>
> > Ideally, we'd define an isTransformed flag, and require it to be set for
> all tables
> > that are transformed (including 'glyf' and 'loca'); this would imply
> that font producers
> > would have the option of NOT transforming 'glyf' and 'loca' if desired.
> But existing
> > fonts have these tables transformed, and do not have the flag set; to
> avoid breaking
> > compatibility with them, perhaps we need to specify that those two
> tables are
> > ALWAYS transformed, and the flag is ignored.
>
> I think that we made a reasonably strong case for glyf/loca transforms to
> be normatively mandated, and the compression gains definitely justify an
> additional implementation complexity, so I see no need to change that. So
> yes, stating the fact that glyf/loca transforms are always applied,
> regardless of the flag setting, will solve the problem of backward
> compatibility with existing woff2 fonts.
>
> Thank you,
> Vlad
>
> > For tables other than 'hmtx' (and 'vmtx', which can be handled
> similarly), setting the
> > isTransformed flag would currently be an error, as no transform is
> defined for them
> > and the decoder wouldn't know what to do.
> >
> > JK
>
>