Re: SVG <glyph> element spec

On Dec 19, 2012, at 6:51 PM, Dirk Schulze <dschulze@adobe.com> wrote:

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

Opera supports the font module from SVG 1.2 Tiny, which just allows the d attribute. IIRC we couldn't find another viewer with full SVG 1.1 fonts support and decided to use the limited font module from SVG 1.2 Tiny instead of SVG 1.1 for SVG2. This would actually address your concerns. Cameron/Erik please correct me if I am mistaken.

The SVG WG decided to not spend resources into SVG Fonts but support SVG-in-OpenType instead.

Personally, I would be fine with removing SVG Fonts from the SVG2 spec. It is still part of previous SVG specifications. Creating a standalone module SVG Fonts based on SVG 1.2 Tiny would work for me as well.

Greetings,
Dirk


>> 
>> 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 07:38:13 UTC