Re: font formats and SVG2

John Daggett writes:

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

If it were as lean and mean as possible it would be called VML.

David


----- Original Message ----- 
From: "John Daggett" <jdaggett@mozilla.com>
To: "Alex Danilo" <alex@pagefire.com>
Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>; <www-svg@w3.org>
Sent: Thursday, March 03, 2011 8:19 PM
Subject: Re: font formats and SVG2


> 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 02:40:20 UTC