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

On Tue, Jun 1, 2010 at 8:23 PM, Doug Schepers <> wrote:

> Robert O'Callahan wrote (on 6/1/10 12:42 AM):
>     <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>
>>    <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.

OK, good to know, thanks.

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

Full SVG 1.1 Fonts are not implemented in any browser (last I checked) and
are indeed challenging to implement. Are there use-cases for full SVG 1.1
Fonts that are not adequately addressed by just including the SVG content
inline in the document and providing a mechanism to associate text with that

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

True. My point here is that if there was a significant amount of content
browsers need to be compatible with, that would be a compelling argument for
implementing SVG Fonts even if they don't provide significant benefits over
WOFF. But AFAIK this is not the case. Jeff Schiller suggests that it might
become the case due to platform limitations of the iPhone/iPad; I think
we'll just have to wait and see.

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.

That sounds very good. In light of that, would it be reasonable to ask Hixie
to remove the SVG Fonts tests from Acid3?

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah

Received on Tuesday, 1 June 2010 18:36:55 UTC