worrying size changes round-tripping, lost 10% of file size.

Two fonts dropped about 10% of file size after going through ttx and back - without any message, etc. again apologies this is with fedora’s ttx.

-rw-rw-r--. 1 Hin-Tak Hin-Tak 6656004 Oct 27 00:20 cfmingeb-ttxed.ttf
-rw-rw-r--. 1 Hin-Tak Hin-Tak 2950628 Oct 26 23:47 cjsongeb-ttxed.ttf

-r--r--r--. 1 Hin-Tak Hin-Tak  7235272 May 21  2003 cfmingeb.ttf
-r--r--r--. 1 Hin-Tak Hin-Tak  3275360 May 21  2003 cjsongeb.ttf

I believe they were publicly available and free-use at some point in the past (judging from where I keep them), though I do not know where I got them from.

173907f1f3f4404d4617c9fa6318907a  cfmingeb.ttf
4f7c3c0b2b99648dcd8457b96614038b  cjsongeb.ttf

[justvanrossum]

The flaws we’re talking about are repeated coordinates, that ttx properly packs using the flagXsame or flagYsame flags, but wasn’t in the originals. That information is not retained in the XML format, as it is of no importance to the semantics of the data.

[HinTak]

Yes, Werner summarized the problem with general file fuzzer quite well - they generate piles of invalid fonts which do not pass the most rudimentary checks. It takes an incredible amount of computing time/resources with the general file fuzzing approach to explore rarely-used code paths and the darker corners of font engines.

I managed to “fuzz” some fonts to get at a few specific corner cases, by inserting PUSHW’s randomly in the hinting instruction stream. (perhaps POP’s would do also). This approach has its limits as the font engine soon aborts due to stack overflow/underflow. This also applies to hinting only, and not contours.