[Webkit-unassigned] [Bug 61561] add support for "on demand" webfonts

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=61561


Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |rniwa at webkit.org
     Ever Confirmed|0                           |1




--- Comment #11 from Ryosuke Niwa <rniwa at webkit.org>  2011-08-09 14:06:34 PST ---
I'm very excited about this bug!  However, I strongly believe we should do this discussion on an open mailing list where folks from Mozilla, Opera, etc... can participate.

(In reply to comment #10)
> > So rather than inventing a new way for client/server to communicate, 
> > I'd try to latch onto existing concepts. We know a font can be broken 
> > up into multiple files server-side and you can serve up pieces based 
> > off unicode ranges.
> 
> For many scripts using Unicode ranges is likely to give a good win. For example, Droid Sans has ~ 2500 characters but less than 100 are needed for US English docs, less than 256 for most European docs, less than 100 for Hebrew. Splitting by Unicode range would reduce the webfont size significantly and in general most web pages using one of they scripts know which script they are using.

Hebrew and Arabic are very good examples here since they only use very small subset of Unicode.  I'm not sure how much of win we have for CJK since even a very small blog article may contain 500-1,000 unique characters (guess still much better than loading the whole 20,000 character worth of glyphs?)

> We've done mapreduces to figure out the popular characters in CJK pages on the web. It takes around 4K character to cover 75% of Japanese web pages. It takes about 4K to cover 75% of Korean characters. It appears that Chinese may be in the same range but we need to redo the mapreduces separating Simplified and Traditional Chinese (Over the 75% popularity range there is uncertainty since the results include some questionable characters. Hence we are redoing the mapreducs.). A subset of 4K chars is about 25% of a CJK font so splitting the font based on popularity to hit 75% of webpages is a modest win since 25% of all CJK webpages would require additional subsets.

It appears that what we need is a generic way of pulling multiple Unicode code point ranges.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.