Re: SVG <glyph> element spec

On Dec 19, 2012, at 6:41 PM, Cameron McCormack <cam@mcc.id.au> wrote:

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

You ask for concentrating on SVG-in-OpenType (which I strongly support), and bring up a new text proposal at the same time? :)

Greetings,
Dirk

> 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:52:02 UTC