Re: Chrome to support WOFF

At some point, the TTFs/OTFs will need to be there somewhere, at least
in memory. After all, web browsers do use the system rasterizer to
render the text (at least on some systems), so they need to pass a piece
of SFNT into the OS somehow, because at this moment, the OS can process
the SFNT structure but not the WOFF structure natively. (It's kind of
similar to converting a PNG or JPEG into some sort of image buffer and
passing that to the rendering engine).

But I agree that storing the TTFs or OTFs in bare form as separate files
on the client's drive is something that should be avoided.

Best,
Adam


On 10-04-24 00:41, Chris Lilley wrote:
> On Saturday, April 24, 2010, 12:31:13 AM, Thomas wrote:
>
> TP> Does that mean WOFF fonts will be TTFs/OTFS in the cache? Will the
> TP> non-WOFF fonts be exposed or accessible anywhere?
>
> That is a good and reasonable question. I would assume that the web-side cache would relate to resources as fetched from the web, and that any transcoded or derived resources, rather like the results of XSLT stylesheets, would be internal to the application and not exposed to the outside.
>
> But it is certainly a good idea to ask that on the bug page.
>
> TP> On Fri, Apr 23, 2010 at 2:19 PM, Chris Lilley <chris@w3.org> wrote:
>   
>>>> It appears that we have decided to implement WOFF in Chromium. I plan on adding
>>>> support to OTS (our transcoder http://code.google.com/p/ots/) so that the transcoded
>>>> fonts will be TTFs on the other side. That way, few WebKit changes should be needed.
>>>>         
>   
>>>> Any objections, speak now.
>>>>         
>>> http://code.google.com/p/chromium/issues/detail?id=25543#c10
>>>       
>
>
>
>
>
>
>

Received on Friday, 23 April 2010 23:23:14 UTC