<html><body>
<p>On Monday, April 06, 2015 5:18 PM Richard Wordingham wrote:</p>
<p>On Mon, 6 Apr 2015 15:11:27 +0000 “Levantovsky, Vladimir” <Vladimir.Levantovsky@monotype.com> wrote:</p>
<blockquote><p>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).</p></blockquote>
<p>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.</p>
<p>[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.</p>
<blockquote><p>I don’t believe that overlapping tables are allowed in any font spec, and it is definitely a security risk.</p></blockquote>
<p>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.</p>
<p>[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.</p>
<blockquote><p>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.</p></blockquote>
<p>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.</p>
<p>[VL] Can you please elaborate on such a scheme?</p>
<p>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.</p>
<p>[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)?</p>
<p>Thank you, Vladimir</p>
<p>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.</p>
<p>Richard.</p>
<p>List archive: <a href="http://email.monotype.com/wf/click?upn=kxJiGh-2F9YUZUQlb9NXj3zgF-2FR9aSpfr7oyYGZ2RWQSN8xmTc6izQfY8GI5O7CKNx_J0Ubaei5HA3XL039ePvaTIKlP3BYkaS-2FPxqEvs36nef0tBrc0EXrF4KBiEx2EtFvYrvT1P2P3yeApCwwFrmLjJcIe4Kur4s98PpPoqcubZF1-2Bm9mPchGqgEeS0KiIefbKDa-2FVb48o7CdguntMl1VNdqFIbD8nSN8s7-2FXJ2i1JhlLGto62r95COkql6VV9veaYK9W2IsKVHFGBVNiJthIFZTx1bUBq6CW-2FDe8PkezU9c-3D">http://www.indx.co.uk/biglistarchive/</a></p>
<p>subscribe: opentype-subscribe@indx.co.uk unsubscribe: opentype-unsubscribe@indx.co.uk messages: opentype-list@indx.co.uk</p>
<img src="http://email.monotype.com/wf/open?upn=J0Ubaei5HA3XL039ePvaTIKlP3BYkaS-2FPxqEvs36nef0tBrc0EXrF4KBiEx2EtFvYrvT1P2P3yeApCwwFrmLjGYiiqIL6eO9VlzMrrGKh6pYr84JzdSFD-2FTlZlJHsWIoA7mczssEJvpxFcl3wyC1yLJDPArQpIqtt3z9rta1sFvKrQN3tucaq4oNw5rO85KMfSNMgi-2F8bxQD-2Fa0AuQpPLy-2FXTh26zZ37TZFIjTTJWmk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>