Re: Chrome to support WOFF

Hi Sergey,

> > The Chromium code does the extra step of reconstructing the entire
> > font, sanitizing a specific set of tables and omitting all others
> > (including GSUB, GPOS, and GDEF currently).  
> 
> Wouldn't removing OpenType layout table break all international fonts?
> Also, modification of original font file (even automatically by
> application) may be incompatible with some font licenses, isn't it?

Yes, removing these specific tables is problematic for exactly the
reason you point out, that it will break rendering of fonts for
complex scripts and eliminate the possibility of rendering with
kerning and ligatures (which is possible in Chrome using
'text-rendering: optimizeLegibility').

The license issue is also there although I think that's somewhat murky
since applications are always manipulating font data to some degree,
removing those tables is equivalent to rendering with an font engine
that doesn't support OpenType layout.

> > This was done because of concerns about potential security 
> > bugs lurking in platform font API's, especially on Windows. 
> 
> Do you think that font processing code in Windows is so insecure that
> it justifies crippling font functionality?  

Unfortunately, if obscure bugs in Uniscribe rendering can be utilized
for exploits, browser vendors will do whatever is necessary to avoid
that code path, even if it means less than ideal font functionality. 

The problem here is that Uniscribe is a black box and my understanding
is that the Chrome team did some fuzzing of those API's and found
enough issues to be concerned (fixes for the bugs they found were
patched in Windows updates last fall and earlier this year I believe).

Regards,

John

Received on Sunday, 25 April 2010 00:38:04 UTC