W3C home > Mailing lists > Public > www-svg@w3.org > March 2011

Re: font formats and SVG2

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
Message-ID: <896784011.506621.1299201581160.JavaMail.root@cm-mail03.mozilla.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

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.


John Daggett
Received on Friday, 4 March 2011 01:20:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC