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