Re: SVG Fonts [Re: Minutes, SVG WG Brussels f2f day 4 (Monday)]

Hi, Robert-

The minutes don't quite capture the real discussion.  Let me clarify...


Robert O'Callahan wrote (on 6/1/10 12:42 AM):
> On Tue, Jun 1, 2010 at 2:52 AM, Chris Lilley <chris@w3.org
> <mailto:chris@w3.org>> wrote:
>
>     <fat_tony> ... I propose for SVG 2.0 we mandate you use WOFF

As far as I know, everyone active on the SVG WG agrees that WOFF should 
be a mandated font format for SVG 2.0.  I hope that's not controversial.


>     <fat_tony> ... and have SVG Fonts as an optional features
>
> I strongly support this.

Chris actually proposed that complete SVG Fonts be broken out into its 
own module, a separate specification, which would be optional for 
implementers; in fact, I think I was the first to propose this as a way 
forward some months back, so I think it's a good plan.  We do not plan 
to introduce optional features into the SVG 2.0 spec itself, because we 
want broad interoperability.


>     <fat_tony> DS: I have a counter proposal, right now we have SVG Tiny
>     1.2 fonts in Opera and Webkit
>
>     <fat_tony> ... and there are patches for FireFox
>
> Actually there aren't.

I've been told by Dave Crossland (from Open Font Library, and an Invited 
Expert on the new Fonts WG), that there is a patch for SVG Fonts for 
Firefox, but that it hasn't been accepted.  I haven't verified this 
myself, but I assumed it was true.


>However, creating SVG Font support is not a big
> deal, at least up to the level of SVG Tiny 1.2 (which is all Opera and
> Webkit support). My concern about SVG Fonts is that they're just
> unnecessary for the Web platform.

I agree that WOFF fonts are more important, but I don't like going down 
the path of deciding which features are "necessary for the Web 
platform", because that's rather fuzzy rhetoric.  There are many 
features of HTML5 that are simply "nice to have", for example... not 
"necessary".  I think a better metric is an analysis of how much 
developer/designer demand there is for a feature, and how much it 
enables new expression of content, tempered by how hard it is to 
implement and maintain.  Maybe SVG Fonts doesn't hit that sweet spot... 
but designers have told me repeatedly how much they love SVG Fonts, and 
I'm regularly asked when they will be ubiquitous in browsers, so I think 
it's a reasonable avenue to explore by collecting use cases and 
requirements and looking at the costs.


>     <fat_tony> DS: To me as a developer, there are couple of different
>     things about SVG Tiny 1.2 fonts
>
>     <fat_tony> ... you can have overlaps
>
>     <ChrisL> http://www.w3.org/Fonts/WG/
>
>     <fat_tony> ... which you can't do in traditional fonts
>
>     <fat_tony> ... and you can do scripting
>
>
> It's not clear from the minutes what these "overlaps" are.

OpenType fonts are simply outlines, while SVG fonts can have stroked 
intersections and "crossed paths".  This is useful for illuminated 
manuscript capital letters and other design features.  There are other 
ways to achieve this, such as the modification of <altGlyph> that I also 
proposed which would not require SVG Fonts, but which preserves the text 
semantics.

"Scripting" refers to the fact that you can generate SVG Fonts 
clientside via script, useful for online SVG editors.


> I think the case for using WOFF in SVG is very strong. Opentype is much
> better than SVG Fonts in almost every respect: hinting, subpixel
> antialiasing, i18n support, availability of fonts, familiarity to
> authors, support in font design tools, advanced formatting features (see
> CSS3 Fonts spec), and so on.

Agreed.


> Therefore the question is, what do SVG Fonts offer that WOFF can't?

Note that weakening SVG Fonts to the level of SVG 1.2 Tiny fonts doesn't 
have much benefit over WOFF, so that's a bit of a strawman; full SVG 1.1 
Fonts, while more challenging to implement, also provide some 
significant design advantages, particularly for large font-sizes like 
headings, poster-style graphics, and other places where font detail can 
be seen and appreciated... stuff that's done in InDesign or similar 
tools, but which is not found on the Web because you can't easily do it 
on the Web.  SVG was not intended for HTML-style documents, but for 
products of graphical design that HTML can't do.  SVG Fonts is part of that.


> Considering SVG Tiny 1.2 Fonts, and not knowing what "overlaps" are,
> I've heard three suggestions:
> 1) More predictable rasterization
> 2) 3 points on the Acid3 test
> 3) Compatibility with SVG content that already uses SVG Fonts.
>
> But none of these are compelling:
> 1) You don't get truly predictable rasterization because the SVG spec
> doesn't define rasterization. Also, you can use
> text-rendering:geometricPrecision to disable hinting in Opentype
> rasterizers, giving you most of the available predictability.
> 2) Adding features to the Web platform to pass Acid3 is the tail wagging
> the dog.

Agreed.  I don't consider the Acid3 test an important metric.  The only 
reason the SVG tests in there are so obscure is that the rules that were 
laid out for inclusion of a subtest were so convoluted and artificial, 
and the resulting implementations were gamed for passing the test 
without providing useful new functionality to developers; I'm sure that 
wasn't the intent, but it was a predictable outcome.  Acid3 is a 
publicity stunt that the SVG WG thought was useful for a single purpose: 
to emphasize that SVG is part of the Web platform.  The details of the 
SVG subtests are not the important part.



> 3) There seems to be very little SVG Fonts content on the Web that's not
> testcases. Maybe there's more in "walled garden" environments, but
> that's not an argument to have SVG Fonts on the Web. If a deluge of such
> content migrates to the Web, we can make SVG Fonts non-optional at that
> time.

Many of the cases of folks using SVG Fonts may be covered by WOFF.  But 
there were still quite a few examples out there, which may be hard to 
find because Google either doesn't index SVG effectively or doesn't 
display SVG content in its results.  I have seen a lot of content on the 
Web that used them, particularly in the early days of SVG, but it's hard 
for me to find again; I'm not expecting you to treat that as anything 
more than anecdotal, but the poor support in browsers is the 
chicken-and-egg with regards to usage.

I agree that we can look at this critically later; I expect that there 
will be more SVG Fonts now that Inkscape supports font creation.

I don't think that we disagree about the fundamental approach going 
forward; SVG Fonts should be developed in a separate module, and 
implementations should decide whether they support it depending on 
demand.  I think there will be a strong case for it, but that's 
something to be decided later.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 1 June 2010 08:24:06 UTC