Re: SVG <glyph> element spec

On 20/12/12 1:59 AM, Stephen Chenney wrote:
> It seems that no browser supports arbitrary geometry inside a <glyph>
> element. Only path data in the "d" attribute of the glyph is supported,
> and then only on Opera and WebKit (as far as I can tell). There are no
> W3C tests for non-path glyphs that I could find.
>
> I propose we drop the container aspect of glyph and insist on path data
> only. The complexity of implementing arbitrary geometry inside <glyph>
> makes it unlikely to be supported.

In my view, we should push forward with the SVG-in-OpenType proposal to 
satisfy the use case of colourful, animated fonts, and for smaller 
(one-off) uses of graphics for text, we should introduce a new feature 
that allows graphics to be associated with a text string.  For example, 
something like:

   <text>
     <tspan x="100" y="100">Introducing...</tspan>
     <tgraphics>
       <path d="..."/>
       <g> ... </g>
       <!-- whatever other arbitrary graphics -->
       <tspan>Wizbango</tspan>
     </tgraphics>
     <tspan x="400" y="300">... the new laundry detergent</tspan>
   </text>

Maybe you would want to allow an x="", y="", horiz-adv-x="", ascent="", 
descent="" on the <tgraphics>, so that you could select the text nicely.

Alternatively, simpler would be to have <tgraphics> as a top level 
element and not allow it to be inline with regular text content.

> I also discovered that it is essential that a horiz-adv-x and related
> sizes be given for the font, otherwise the width is undefined. I think
> the spec should be explicit about this somewhere in the <glyph>
> discussion. Maybe we could also define it such that the advances, if
> undefined, come from the bounding box of the path.

Or, if you want something simpler, we could default it to whatever 
units-per-em is.

Received on Thursday, 20 December 2012 02:42:24 UTC