RE: SVG Fonts [...]

What a gret discussion this is! I love hearing from the community on these issues.  

For SVG Fonts, we identified the following use case (though we recognized others)

As a web page header:
a) Have a user select the header
b) Have the header be indexable
c) Accessibility

SVG Selection is an issue in general and needs to be solved independent of fonts.
Indexing a header for search engines based upon some text on a page isn't as compelling.  You can use <title> to index just as well or even better
Accessibility is best solved with <title> <desc> or ARIA.

We all agreed that SVG Fonts would not be used for document text, so we are only talking about large print, header like info.

<use> is a very powerful and nice feature and allows me "use" an svgdocument just like a font for the vast majority of use cases.

<use .. xlink:href="svg.font#f">
<use .. xlink:href="svg.font#o"> 
<use .. xlink:href="svg.font#n">
<use .. xlink:href="svg.font#t">

But frankly, I don't see developers going this far, I see developers, if they want to use SVG as a header simply referencing it inline

<html>
    <img src="header.svg">

or
<g id="myheader">
...
</g>

As mentioned previously, when we look at the future of SVG, especially as it relates to HTML, in order to succeed at delivering the real "vector graphic" core values to the web, I submit we must let go of some of these, in my mind, edge cases.  It took six years (?) to push out SVG 1.1 2nd edition into almost editors rec. There is a high cost to every module: testing, writing, implementing, maintaining.  Any area where we in the SVG spec can trim back and focus on the primary use cases for SVG, I see as an opportunity.  And note, that Chris from the working group didn't propose to eliminate the Fonts module, but rather make it optional.  Essentially, instead of having the SVG Working Group define the expected standards (as in the previous approach of Tiny, Basic and Full), the intent was to allow customer demand drive features. As far as I know, no vendor has implemented SVG Fonts in full, and there are interoperability issues.  SVG Fonts are useful for devices, and other scenarios.  I would love for someone to point me to more than 100 web pages that use them.

This same issue goes back to other features such as animations for example.  The SVG group did a great job leading the effort in integrating SMIL; while this is not my favorite choice for animation (declarative) it is more toolable.  Yet regardless of my opinion and consistent with the group's opinion, whether or not SMIL moves forward is irrelevant.  We need a consistent story with HTML and CSS on animation.  That should be the animation story for SVG.  

I believe the same goes for Fonts. How much legacy are we going to support (or in some cases, build)?

If I were spend my dollars on the SVG working group's investments and resources for browser implementors would you spend them on:
    HTML/SVG/CSS convergence for properties, attributes, elements and features such as animations, fonts, transforms and filters.
    Investigations into new, powerful features (such that were shared with us on diffusion curves, parameters, etc)
    Fix the SVG DOM

I would like to see SVG 2.0 get back to core values, and get to the community in a short amount of time.  

________________________________________
From: www-svg-request@w3.org [www-svg-request@w3.org] on behalf of Dr. Olaf Hoffmann [Dr.O.Hoffmann@gmx.de]
Sent: Thursday, June 03, 2010 5:27 AM
To: robert@ocallahan.org; www-svg@w3.org
Subject: Re: SVG Fonts [...]

Robert O'Callahan:
> 2010/6/3 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
>
> > I think, these are pretty different use cases, to provide a font
> > for reading a larger amount of text or to provide some specific glyphs
> > within
> > the same document for reasons like corporate design, advertisement,
> > design etc.
>
> For the latter use-case, why not just insert the graphic inline or use
> <use> to include the graphic? If you want the text available for searching
> or accessibility, it'd be trivial to extend SVG so you can associate
> Unicode text with particular graphic objects. Something like
> <g>
>   <textContent>Mozilla</textContent>
>   ... Mozilla wordmark here ...
> </g>

You mean something like:

<g ...>
<title>Mozilla ...</title>
<desc>
Path representation of the text: ...
(including corporate design intentions)
</desc>
<path d="... lot of data ..." />
<path d="... lot of data ..." />
<path d="... lot of data ..." />
...
</g>

Sure, this is possible and using title and desc is always a good
option to provide more information about the intented interpretation
of graphics (if the viewer of each user provides some comfortable
access to this additional/alternative information).
However modifying the text (fixing bugs, other language for
example at wikimedia) is difficult  - ok, if you only provide the
SVG-glyphs for the characters needed, modifying might be difficult
as well, but if this is predictable, the author can provide already
some more glyphs to cover such common changes.

Maybe with such an application you will end up with a font of
50 to 100 glyphs, even if in one language version only 20
glyphs are used. However, many glyphs of this font will
share several path segments, what reduces the work again
dramatically. And there is a simple option as well to add some
missing glyphs (for example Umlaute for a translation from
english to german or some accents for english to french, spanish etc)

This option to apply minor changes to the content without touching
the design - or to add a previously missing glyph in the same style
for another language - is an important aspect as well, because in
such communities as wikipedia, wikimedia, wikibooks authors are
changing and the use cases for the graphics may change as well.
To be able to modify or to fix something with a simple tool like a
text editor provides the interesting option, that more authors
are able to contribute relevant content and with better quality.
>From this point of view, it is always more favourable to have
as much as possible in the same XML format, in this case to
have the relevant graphics in one file in the format SVG.

I have seen HTML-webpages with one GIF per glyph.
This can be the result, if nothing works properly in typical
viewers or the alternatives are too complex for the author.
If this WOFF really works in many viewers and there are a lot
of those fonts without licensing problems if republished by common
authors or some organisations provide open font servers with the
possibility for any author to link such fonts, this will be a good option
to avoid this nonsense for HTML-webpages in the future.
SVG-fonts are a good option to avoid something similar within
graphics and for the requirement, that the graphical document must
contain the used font itself.
This is not either-or, both solves or avoids problems if used
properly.

> That's far easier to implement than full SVG 1.1 Fonts. In fact, viewers
> need not implement anything at all. It's more flexible since you can
> include absolutely anything in the graphic content. It's probably also
> easier to author in most cases; the author just designs the graphic
> in-place, and then annotates it with the underlying text.

Sure, in the past 10 or 15 years I have seen a huge amount of
'simple solutions' for problems, that would have not occured, if
the author had the knowledge and capabilties and interest to
do it properly - and the specified effect can be really achieved
in all major viewers. Typically these 'simple solutions' are rubbish,
if modifications are required or the author changes or there
is a longer time until the same author has a need to change
something ;o)

> With SVG Fonts
> the author has to design the graphic, then break it up into individual
> glyphs and move them out into a font.

I think, typically one starts to create each single glyph (maybe even better
to start with some characteristic path segments found in the same way in
several glyphs), puts all in the font and uses this as a font, but I'm no
designer and no font expert. Indeed it would not be very effective to
paint for example 1kb of text manually, separate it in 1000 glyphs,
putting this in a font and use this to represent the text ;o)

But no doubt, not all authors will prefer readable text content over
path-soup. As can be seen at many places, several people believe
more in pictograms than in the written word, even if only a minority
can identify, what each pictogram means ;o)
Some have to provide text due to some social pressure.
And some might want to do it as best as possible
just for fun or because they can or want to show,
that they really can write and read ;o)

>
> IMHO a "font" only makes sense if you're going to combine character glyphs
> in more than one way. Otherwise it's just an inconvenient way to reference
> images.
>

This happens, if you have to change the language or if you have not
just a simple 5-or-6-glyph-logo (Mozilla with one ligature for 'll' or 'ill'),
but some more words.

Olaf

Received on Thursday, 3 June 2010 13:59:42 UTC