#9 TTX does not pad final table

closed-invalid
None
5
2012-03-20
2012-03-20
Chris Lilley
No

TTX does not pad the final table to a multiple of four bytes. This would cause the Google font checker to reject the font; except it currently has a work-around specifically because of TTX-generated Takao font, which is the default Japanese font on new Ubuntu distributions. In turn, this work-around causes all browsers that use the Google font sanitiser to fail directory-4-byte-002 in the WOFF test suite.
It would be great therefore to
a) fix this in TTX
b) for the Ubuntu folks to remake Takao font with the fixed TTX
c) for Google to remove their workaround
d) for WOFF to meet its Candidate Recommendation exit criteria and become a W3C Recommendation.

Links:
http://code.google.com/p/chromium/issues/detail?id=47960
http://code.google.com/p/chromium/issues/detail?id=109813
http://w3c-test.org/framework/results/woff-ua/

Discussion

  • FontTools *always* pads tables to 4-byte boundaries. The problem-fonts must've been post-processed with another tool. I just round-tripped the font with the "offending" vtmx table, and it gets padded just fine.

     
    • assigned_to: nobody --> jvr
    • status: open --> open-invalid
     
  • Tal Leming
    Tal Leming
    2012-03-20

    As best I can tell, this issue was resolved with change 562 (http://fonttools.svn.sourceforge.net/viewvc/fonttools?view=revision&revision=562) and it is part of the current distribution. I round tripped takao-fonts-ttf-003.02.01/TakaoPGothic.ttf using both the current distribution and the trunk. The results were padded even though the original source was not in both cases.

     
    • status: open-invalid --> closed-invalid