W3C home > Mailing lists > Public > www-font@w3.org > April to June 2012

Re: Announcing new font compression project

From: Just Fill Bugs <mozbugbox@yahoo.com.au>
Date: Sun, 01 Apr 2012 14:24:39 +0800
To: www-font@w3.org
Message-ID: <jl8saa$b2m$1@dough.gmane.org>
The removal of random access to the glyf table is bad. It won't do 
anything good to CJK fonts with the tiny bit space saving.

It might takes only 1 second to load a 100KB latin font, while for a 3MB 
CJK font, it will take 30 seconds. Are you sure users are willing to 
wait for 30 seconds before seeing the webpages pop up with some fancy 
font faces?

glyf should be allowed to be compressed by segment and there could be a 
new table similar to loca which maps glyph index (maybe by range) to 
compressed glyf segments. The a browser can start showing text in the 
new font face progressively while the whole font file being downloaded 
in the background. The raw glyf data can be optimized such that the most 
frequently used glyphs for certain language are grouped together.


I'd rather lost a little bit compression gain over having to wait for a 
complete CJK font to be downloaded before anything shows up.

Of course this compression by segment for the glyf table can be optional 
to please some latin font users who hate to download extra 10KB 
cache-able data.

A possible alternatives I can see is to provide something similar to the 
FTC format which contains paritial subfonts of the same type face. Each 
subfont contains a part of a complete cmap range for the same font. A 
browser can download and cache just parts of a big font. This sounds 
more like a hack but could be easier to implement for browsers. It is 
also cleaner to maintained on the server side since we just use a single 
WOFF font with subfonts instead of myface-0-1000.woff, 
myface-1001-2000.woff, myface-2001-3000.woff...
Received on Sunday, 1 April 2012 12:23:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:43 UTC