- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 3 Mar 2011 17:19:41 -0800 (PST)
- To: Alex Danilo <alex@pagefire.com>
- Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, www-svg@w3.org
Alex Danilo wrote: > >Taking SVG-defined outlines and generating a font via FontForge is a > >*trivial* process. Converting these to OpenType allows them to be used > >as input to *text* rasterizers (e.g. DirectWrite, FreeType, ATS) as > >opposed to purely graphic renderers. Without the use of a text > >rasterizer, the results will not be subpixel antialiased, which > >typically includes rasterization techniques tuned specifically for text. > > Our implementation already uses a different sub-pixel filling technique > when rendering the paths for an SVG font to improve text readability. > > Your assertion is false. This is actually precisely my point, SVG font implementations need to do a lot of work to duplicate the functionality of *existing* OpenType font rendering pipelines. Subpixel antialiasing is no easy task to implement, it requires details of the target display and an understanding of how to hook in user settings to mimic the look of other text (e.g. the ClearType control panel on Windows). It's great that you guys went the extra mile here. My argument was never that it would be impossible to make SVG font rendering match the quality of OpenType fonts, it's that this effort is duplicating functionality that already exists and doesn't offer much in the way of added benefits. In a more modular version of SVG, the core module should really be as lean-and-mean as possible. SVG fonts (both Tiny and Full versions) should be in a separate module, not part of the core. Regards, John Daggett
Received on Friday, 4 March 2011 01:20:14 UTC