RE: TypeCon Presentation Draft

On Thursday, August 05, 2010 6:25 PM Tal Leming wrote:
> 
> Hi Everyone,
> 
> Below is the current rough draft that Erik and I have put together for
> the WOFF presentation at TypeCon. Please let us know what you think.
> 

Hi Tal,

Thank you very much for putting together the draft outline of the presentation, I think this is a good start that provides meaningful overview of the events that brought the industry to where we are today, the benefits of WOFF for both browser and font vendors, etc. I have some comments, please see below.

> Do we know how much time we have to give the presentation?
> 

According to the TypeCon program, there is a one hour and 15 minutes time slot allocated for all webfont-related presentations. This time will be shared between Roger Black (speaking about user experience), Bryan Mason (on font metrics), Raph Levien (Google API) and you and Erik (WOFF). I would consider preparing a compressed presentation that should take 15 min with follow up Q&A discussion during the web font panel.

> 
> ###
> 
> - A brief history of WOFF.
> 	- @font-face was becoming a hot topic in 2009. Everyone was
> looking at the same issue from different perspectives.
> 		- Web developers wanted fonts.
> 		- Font makers wanted a long term solution.
> 		- Browser makers wanted a solution that didn't require too
> much new technology and that didn't place them in a legally precarious
> position.
> 		- Lots of shouting and finger pointing from all sides.
> 	- A variant of EOT was proposed.
> 		- Some browser makers were skeptical.
> 		- The implementation of the format in IE had some important
> bugs.
> 		- The discussion became increasingly less productive.
> 	- Jonathan Kew, at Mozilla, invented a format called ZOT.
> 		- It was conceptually similar to EOT, bt didn't have the
> legacy concerns.
> 		- Some of the browser makers expressed interest.
> 		- Font makers did not express much interest.
> 	- We proposed a format called .webfont.
> 		- It was a ZIP package containing a font and some XML
> metadata.
> 		- Font makers liked our idea and started speaking up in
> favor of it.
> 		- The browser makers seemed interested, but had some
> concerns.
> 	- Håkon Wium Lie suggested that ZOT be merged with .webfont.
> 		- We did. WOFF was born.
> 	- A consensus started to form.
> 		- Some font makers liked it and publicly endorsed it.
> 			- [show supporter names]
> 		- Some browser makers liked it and publicly endorsed it.
> 		- The W3C, which had been following the developments all
> along, became interested.
> 		- This is very important because we have a broad level of
> agreement about the benefits and necessity of the format.
> 	- Mozilla, Opera and Microsoft formally submitted the spec to the
> W3C for standardization.
> 	- The W3C accepted and formed a Working Group.
> 			- [show participant logos]
> 				- Adobe
> 				- Apple
> 				- Dave Crossland
> 				- Google
> 				- Bitstream
> 				- LettError
> 				- Microsoft
> 				- Monotype Imaging
> 				- Mozilla
> 				- Opera
> 				- Tiro Typeworks
> 				- Type Supply
> 	- Everyone is working together. Typography is important.
> 		- Some font makers are already using WOFF.
> 		- Lots of other typography developments in web technology.
> 			- CSS3 features, etc.
> 		- Exciting time for typography!
> 

This is all good and useful info, but given the limited time for the presentation I think we should give it a bird's eye view - IMO the main idea here is to show that the industry at large have come to a point where a *nearly perfect* solution was found that everybody can happily live with.

> - What is WOFF?
> 	- WOFF is not a font format, it is a font packaging format.
> 	- [File diagram.]
> 		- It contains font data.
> 		- It may contain some metadata about the font.
> 		- It may contain some private data that is only relevant to
> the creator of the file.
> 	- Font data.
> 		- Some terminology first.
> 			- We have OpenType and Open Font Format. They are the
> same thing.
> 			- They are actually SFNT files.
> 			- So are classic TrueType files.
> 			- A SFNT is made of separate sections that contain
> different types of data, called tables.
> 				- cmap contains the glyph to Unicode mapping
> 				- name contains the naming data.
> 				- etc.
> 		- In WOFF, these tables are compressed individually.
> 			- The appropriate decompression functionality already
> exists within browsers.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<======================================
> 		- 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.

> 		- Once the compressed tables have been downloaded, the
> browser can reassemble a perfect copy of the original SFNT data.
> 		- This reassembled font can be handed over to font-
> integrity checkers, rasterizers and so on.
> 	- Metadata.
> 		- This is XML. Common format. Easy to edit and read.
> 		- Contains information about the font.
> 			- [List of elements.]
> 		- These elements are a superset of the data fields in
> formats we have worked with along with some additions that we think are
> necessary.

<<<<<<<=============
> 			- It has been pointed out that the duplication with
> the name table data in the SFNT may not be necessary.
> 				- It may also be necessary.
> 				- Explain example of a designer licensing a
> font to a service and how the metadata can reflect this.
> 				- The name table is also extremely complex to
> interpret.
> 					- Thousands and thousands of possible
> combinations.
> 					- [My quick math shows 150,832 possible
> combinations.]
> 					- Browsers don't want to have to know
> about the deep structures in Opentype.
> 		- These elements may be localized for specific languages.
> 			- They don't have to be.
> 			- We specify a standard protocol for selecting the
> appropriate text.
> 			- User agents already know how to present XML data
> 		- What can be done with this?
> 			- Font makers can include data about the specific
> WOFF file.
> 				- license data
> 				- licensee
> 			- Browsers could show this to users upon request.
> 				- [Diagram showing hypothetical UI.]
> 				- This would be useful to web developers, "What
> font is that?"
=======>>>>>>>>>>>>>

I think it is important to point out that:
- metadata is intended primarily for web authors and general public (website visitors);
- it allows browsers to display font info without parsing font binaries;
- duplicating some fields between font binary and WOFF metadata (e.g. vendor info and URL) may seem redundant but it doesn't necessarily mean duplicating the info presented in those fields - they can point to original font vendor in one case and to distribution source in another;
- this info helps people easily identify typefaces used on the web (and their designers).

> 	- Private data.
> 		- This is entirely up to the creator of the WOFF.
> 		- We don't know what it will be used for, but we know that
> we have needed this kind of thing in other formats in the past.
> 
> - WOFF tools
> 	- (all subject to proper licensing.)
> 	- Jonathan Kew's command line tools.
> 	- Online converters.
> 	- Tal's tools for foundries.
> 		- Validator that may move to the W3C.
> 	- Others?
> 

Thank you,
Vlad

Received on Friday, 6 August 2010 13:38:16 UTC