[OpenType] ISO/IEC 14496-22 Amendment for Font Collections

[Levantovsky, Vladimir]

On Monday, April 06, 2015 5:18 PM Richard Wordingham wrote:

On Mon, 6 Apr 2015 15:11:27 +0000
"Levantovsky, Vladimir" <Vladimir.Levantovsky at monotype.com> wrote:

> Regarding the checkSumAdjustment for the entire font - yes, the
> current spec talks only about fonts, but it is not clear whether the
> entire font includes the table directory and table offsets. If it
> does, then the checkSumAdjustment value calculated for the entire
> font will never be the same once that font is wrapped into a font
> collection (as John Jenkins mentioned earlier), and there is no way
> to correct the issues unless the font is 'unwrapped' from the
> collection (which never happens, should not happen by design, and
> even then the original table order would remain a big unknown).

I see only a small amount of hassle.  The check sum is indeed a check
sum - it does not detect the transposition of longwords.  If two
adjacent tables are transposed the checkSumAdjustment has to be changed
if one cares about the check sums. It is straightforward to recalculate
it as fonts are merged into a font collection.

[VL] 
Yes, transposition of data wouldn’t change the data itself, i.e. a table checksum won't be affected by doing it; however global check sum adjustment calculation includes table directory - when the tables are moved their offsets change, table directory content would have to be modified and the global check sum adjustment would no longer be a correct value. If this is done  while creating a font collection file - one can recalculate all check sum adjustments per each font, or calculate a new single check sum adjustment for the whole font collection file (and zero out other values, I suppose), but the spec is silent about either approach and unless something is changed - there is no way to ensure that check sum adjustments are correct and trustworthy.

> I don’t believe that overlapping tables are allowed in any font spec,
> and it is definitely a security risk.

Could you expand on the claim of a security risk, please.  I'm
interested in tables from different fonts in the same collection.  This
is not actually prohibited by the OpenType specification.

[VL]
Well, I am no security expert but if you allow overlapping tables one can easily doctor the font file content (e.g. to modify table lengths / offsets in a table directory to create an overlap and use it as an exploit to load a malicious data. SFNT structure isn't bullet-proof and anyone can easily add arbitrary data to a font file, but at least you are protected to an extent because a custom table data won't be loaded by a font rasterizer. If table overlaps are allowed, a doctored font data can be used to force loading of malicious data.

> Webfont compressors (both WOFF
> and WOFF2) will invalidate a font with overlapping tables, and this
> is currently a mandatory step for any compliant WOFF/WOFF2 decoder.

Moreover, WOFF2 prohibits fonts' tables overlapping without
coinciding.  (A WOFF contains only one font.)  That strongly
limits schemes that save space in uncompressed font collections.

[VL]
Can you please elaborate on such a scheme?

WOFF2 also prohibits fonts sharing glyf but not loca (admittedly a
perverse combination unless the last glyph in one font contains more
than 3 bytes of ignored junk) and prohibits fonts from sharing loca but
not glyf (a perverse combination or probably requiring the tweaking of
the sizes of the glyph definitions).  This smacks of the authors being
exhausted.

[VL]
Where did you find this info? Why do you think WOFF2 has anything to do with prohibiting table sharing ('glyf' /'loca' or any other table for that matter)?

Thank you,
Vladimir

I strongly suspect that the mandatory compression in WOFF2 would
massively reduce the space-wasting in almost identical consecutive name
tables.  I'm not sure about GSUB; it would depend on the size of the
sliding windows in the compression algorithm, and there could be a
cliff-edge in performance.

Richard.



List archive: http://www.indx.co.uk/biglistarchive/

subscribe: opentype-subscribe at indx.co.uk
unsubscribe: opentype-unsubscribe at indx.co.uk
messages: opentype-list at indx.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150407/35bfdcec/attachment.html>