- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Mon, 9 Aug 2010 17:59:08 -0400
- To: Sylvain Galineau <sylvaing@microsoft.com>, Tal Leming <tal@typesupply.com>, WOFF Working Group <public-webfonts-wg@w3.org>
On Monday, August 09, 2010 5:33 PM Sylvain Galineau wrote: > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<====================================== > > > - Because of the per table compression, a browser can > > > download all or only part of the WOFF. > > > - ** This is purely hypothetical. Any better > > > examples? ** > > > - For example, say the browser sees that the WOFF to > > > download is 5 mb. > > > - Instead of pulling the whole file over, it pulls > > > only the cmap. > > > - It compares the Unicode indexes needed for the text > > > to be displayed. > > > - If the text can be rendered with the font, it pulls > > > over the rest of the data. > > > - If not, it doesn't bother with the rest of the > > > WOFF. > > > =================================>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > > > > As far as the example above is concerned, I am not sure if we should > > say this for now. While it is feasible that per table compression can > > enable progressive download of WOFF files, it would require ability > to > > issue separate requests for download of WOFF header + table > directory, > > and then for each chunk of binary that correspond to a particular > table. > > Since the current version of WOFF doesn't support this functionality, > > I'd rather not mention it, or just say that per-table compression > > enables us to develop new functionality for progressive download in > the > > future versions. > > This could be implemented with HTTP byte range requests today if both > client > and server support them so I'm not sure what WOFF functionality is > missing? > Or are you saying that the format is not yet structured in a way that > supports > this ? If so how ? > You are right. Technically, it is feasible that one can use HTTP byte range request to download WOFF header only, then calculate the table directory size and issue another HTTP byte range request to get the table directory, then look up the table in question and issue yet another request, etc. For this to happen, it should at least be mentioned in the spec. I guess what I meant to say was that currently the spec is absolutely silent about all this, and an attempt to use short presentation to describe advanced functionality that is not even mentioned in the spec may not be a good fit for a top-level introduction / overview of new technology. Regards, Vlad > Otherwise, I do agree that this is probably too deep a level of detail > for the > time allotted. >
Received on Monday, 9 August 2010 22:05:36 UTC