W3C home > Mailing lists > Public > www-font@w3.org > January to March 2012

Re: Getting passes on directory-4-byte-002 - a long story

From: Tal Leming <tal@typesupply.com>
Date: Tue, 20 Mar 2012 15:53:51 -0400
Cc: www-font@w3.org
Message-Id: <228FD4F6-BA6B-4907-AB19-1CD6069DA88A@typesupply.com>
To: Chris Lilley <chris@w3.org>
I talked to Just about this and looked into it myself. This issue was resolved in 2008 (I reported the issue to Just myself back then :-). I checked one of the fonts that was listed as problematic and it was, indeed, not padded.  I round tripped the fonts to .ttx and back to .ttf with the latest release and the version in the trunk. Both resulted in padded files. If TTX is the end of the production chain for these fonts, they should upgrade to the latest TTX/FontTools release. If the problem persists, I'd like to know.


On Mar 20, 2012, at 12:05 PM, Chris Lilley wrote:

> Hello www-font,
> I just submitted this bug report on the TTX font conversion software:
> ================
> 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/
> ==============
> https://sourceforge.net/tracker/?func=detail&aid=3509413&group_id=29196&atid=1613956
> I see that Just van Rossum is one of the developers. My hope is that TTX can be fixed, which allows Ubuntu to update their default Japanese webfont, which allows Google to no longer have to hack around it, which means that implementatiosn which use the google font sanitiser can pass directory-4-byte-002.
> Implementations which don't use Google font sanitiser (I'm looking at you, IE9 and IE10) it would be great to see some passes in this area as well.
> -- 
> Chris Lilley   Technical Director, Interaction Domain                 
> W3C Graphics Activity Lead, Fonts Activity Lead
> Co-Chair, W3C Hypertext CG
> Member, CSS, WebFonts, SVG Working Groups
Received on Tuesday, 20 March 2012 19:54:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:36 UTC