W3C home > Mailing lists > Public > www-font@w3.org > April to June 2011

Re: SVG Fonts inside of OpenType fonts? [Cross-post from www-font@w3.org]

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Mon, 27 Jun 2011 14:19:42 +0200
To: Ben Weiner <ben@readingtype.org.uk>, www-font@w3.org
Message-Id: <201106271419.43097.Dr.O.Hoffmann@gmx.de>
Ben Weiner:
> Hi,
>
> On 27 Jun 2011, at 10:22, Dr. Olaf Hoffmann wrote:
> > Note that a typical fallback for SVG today is to use no fonts at all but
> > the path element even without advanced graphical effects,
> > see for example the SVG output of openstreetmap.org .
>
> When you say 'use no fonts at all' do you mean 'embed glyphs into the SVG'?

First: Do not misunderstand this as a sugestion of a recommended method or
best practice ;o)
Second: What you have to do is, depends on the problem.
I think, openstreetmap.org defines simply paths within the defs element for
each required glyph and reference them with use - therefore they have not
to use fonts at all an no textPath, therefore they have complete control.
Ok, once you have the option to use a well known font and reliable
textPath implementations (no really bad already now), I think, this 
approach can be dramatically improved. There is no real need for
an SVG font here, once they can rely on precise glyphs from a known
font.
This is basically an example how to 'downgrade' a problem in SVG in
such a way, that the graphical appearance is ok even in less advanced
viewer. 
But this can result in rather inaccessible and hardly to understand and to 
modify documents, this should be avoided - we can see in HTML5 what 
happens, if it becomes the idea to follow such cowpaths.

Another example would be a logo, icon, pictogram - you want to have
it exactly the way, you provided it as SVG. If there are viewers doing
something different, you will use generic path data, no text to meat
this requirement.
Similar if you need animated, morphing glyphs. If the font format does
not provide it or some viewer more often used do not interprete the
font format with this capability, again one will use generic path data
to meet at least the graphical requirements, no other font format, 
that does not meet any of the requirements at all ;o)

>
> I used OSM's SVG output last year for a project and there was certainly
> 'real' text at that time, expressed in the SVG like this:
>
>       <text class="highway-name highway-pedestrian-name" dy="0.35px">
>         <textPath xlink:href="#way_normal_2986299" startOffset="50%">Broad
> Street</textPath> </text>
>
> I know that because I used CSS to format them into a locally-available and
> not permissively-licensed font before rendering as PostScript :)
>

The files I created from openstreetmap.org this month (SVG maps of Hannover, 
Germany) contain typically something like this:

<symbol overflow="visible" id="glyph116-50">
<path style="stroke:none;" d="M 3.9375 -6.625 C 3.21875 -6.625 
2.648438 -6.351562 2.234375 -5.8125 C 1.816406 -5.28125 1.609375 -4.554688 
1.609375 -3.640625 C 1.609375 -2.722656 1.816406 -1.992188 2.234375 -1.453125 
C 2.648438 -0.921875 3.21875 -0.65625 3.9375 -0.65625 C 4.65625 -0.65625 
5.222656 -0.921875 5.640625 -1.453125 C 6.054688 -1.992188 6.265625 -2.722656 
6.265625 -3.640625 C 6.265625 -4.554688 6.054688 -5.28125 5.640625 -5.8125 C 
5.222656 -6.351562 4.65625 -6.625 3.9375 -6.625 Z M 3.9375 -7.421875 C 
4.957031 -7.421875 5.773438 -7.078125 6.390625 -6.390625 C 7.003906 -5.703125 
7.3125 -4.785156 7.3125 -3.640625 C 7.3125 -2.492188 7.003906 -1.578125 
6.390625 -0.890625 C 5.773438 -0.203125 4.957031 0.140625 3.9375 0.140625 C 
2.914062 0.140625 2.097656 -0.195312 1.484375 -0.875 C 0.867188 -1.5625 
0.5625 -2.484375 0.5625 -3.640625 C 0.5625 -4.785156 0.867188 -5.703125 
1.484375 -6.390625 C 2.097656 -7.078125 2.914062 -7.421875 3.9375 -7.421875 Z 
M 3.9375 -7.421875 "/>
</symbol>

used with:

<g style="fill:rgb(0%,0%,20%);fill-opacity:1;">
  <use xlink:href="#glyph116-50" x="292.152724" y="675.09767"/>
</g>

I think, the files contain many sympols with some 'glyph*' id not used
at all in the content, maybe they embed always complete 'fonts' -
just in case ...

And they contain a lot of embedded PNGs (pseudo protocol data)
using image - if think, often the same - far away from an optimal use
for internet. To use such maps, one has a lot of work to clean up,
remove style attributes and to reduce file-size ;o)
('scour' from Jeff Schiller can do parts of this job automatically)

No "<text" at all.
If they did it already with text and textPath, such a dramatic change 
to symbol+path+use seems to indicate a real problem with one or
more of the previously used features, maybe because they discovered
a problem in a viewer they consider to be of relevant use ...

Olaf
Received on Monday, 27 June 2011 12:23:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 June 2011 12:23:34 GMT