- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 18 Aug 2006 16:10:02 -0400
- To: Bert Bos <bert@w3.org>
- CC: www-style@w3.org
Bert Bos wrote: > As for the first question, possible reasons that Web Fonts are > implemented so poorly (only one Web browser on one platform, and for > the rest only in SVG viewers): > > a. Syntax not attractive enough Possible. Perhaps something like this... | h1 { font-src: url(http://example.com/fonts/hdl); } I tend to agree that using @font-face is better if you're using large numbers of fonts, but if you're using them for something like a single header, it's a pain. Then again, web development may eventually handle this well enough that it isn't a problem. Either way, I don't like simply "src". It's to generic when referencing what is specifically a font URL. > b. Implementation is difficult I suspect this actually ties in with problem "e", because the best reason to prevent font installation is that the code in the font could be a trojan. Considering that support for new fonts would not be difficult to implement on most systems, it doesn't seem like something that should be blocking. > c. Lack of rights management Since people can already pirate fonts and create images from them to use on their websites, I don't see the issue. Are we to believe that people who pirate fonts are huge accessibility fans?!? Or are we trying to create some big DRM scheme for every file referenced by CSS? Furthermore, we need to ensure that a compliant implementation of CSS can be written as open source. If you can figure out how to do DRM in a GPL project, good for you, but I suspect the best thing would be to simply leave support for specific font formats up to the implementors. > d. Security problems (fonts containing malicious code) It's an issue, but I see it as being an issue related to supporting specific file formats, and as such I feel it's outside the scope of CSS. Implementors should determine what security model they need to use rather than waiting on an elaborate security specification from a working group that isn't necessarily security oriented. > e. Lack of tools for authors to create downloadable fonts This would mostly seem to be a problem with OpenType fonts, which tend to be in the hundreds of kilobytes. Many of the fonts I have on my system are simple TrueType fonts that are only a few kilobytes in size. So some font files could be downloaded without compression, while some will remain huge even with compression. This is similar to situations with image formats, where some file formats are better than others when file size is an issue. I suggest that we just forget about compression entirely and let the best font format win. > f. more? Aural fonts? Support for a profile of SVG as a font format? Ability to use large bitmaps as font files? Support for the Starcraft FNT format? ;) > In conclusion: > > It is currently not clear that allowing an alternative, shorter syntax > (viz., a URL in the 'font-face' property) will significantly increase > the use of downloadable fonts. I was under the impression that only Microsoft supported downloadable fonts, and only via a proprietary format that requires a conversion utiltiy. So the issue seems to be the number of implementations that support common/open font formats, not how difficult it is for the authors to use. > Providing a fallback for failed font > downloads in the form of image replacement and providing some form of > DRM may be more important. Fallback is important. DRM should be handled in the file format.
Received on Friday, 18 August 2006 20:10:27 UTC