W3C home > Mailing lists > Public > www-svg@w3.org > December 2012

Re: SVG <glyph> element spec

From: Stephen Chenney <schenney@chromium.org>
Date: Wed, 19 Dec 2012 10:41:23 -0500
Message-ID: <CAObCcUojDJWB6hTewc1k1r=T193vvYQJXGRWhnFvSu5c=Pu74Q@mail.gmail.com>
To: Rick <graham.rick@gmail.com>
Cc: "www-svg@w3.org" <www-svg@w3.org>
On Wed, Dec 19, 2012 at 10:24 AM, Rick <graham.rick@gmail.com> wrote:
>
> On Wed, Dec 19, 2012 at 9:59 AM, Stephen Chenney <schenney@chromium.org>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'm certain that I had tests at one time for other geometry, but perhaps
> they didn't make it into the test suite.  ?
>
>
>>
>> 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.
>>
>
> Fundamentally glyph rendering is the same as implementing the use element
> with transforms.  Everyone has done that.  I expect the lack of
> implementation is a chicken and egg back burner metaphor mixing thing.
> Most SVG fonts that aren't hand coded to do something special, meaning
> almost all of them, are generated from existing stroked fonts of other
> formats.  With little content and apparently no tests it's easy to justify
> putting font implementation off.  We are on the verge of adding much more
> complexity to SVG than is present in fonts.  Basically fonts are use
> elements with text metrics.  A very powerful concept and relatively cheap
> to code.
>
> And yes, I've done that.
>

As currently worded, <glyph> allows more content than <use>. <use> has
quite significant restrictions on the content that can be used.

"Any ‘svg’, ‘symbol’, ‘g’, graphics element or other ‘use’ is potentially a
template object that can be re-used ..."

"The graphics that make up the ‘glyph’ can be a single path data
specification within the ‘d’ attribute, arbitrary SVG as content within the
‘glyph’, or both."

While <glyph> is similar to <use> from a rendering of basic geometry
perspective, it is not at all like <use> in terms of DOM-bindings, event
handling and other non-geometric properties. This complicates code sharing.
The "arbitrary" aspect of <glyph> is very problematic: consider
<foreignObject>, <image>, <defs>.


>
>> 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.
>>
>
> The spec is clear on this:
> http://www.w3.org/TR/SVG/fonts.html#GlyphElementHorizAdvXAttribute
>

The spec does not have anything to say about default values when the
metrics are not specified (for neither <font> nor <glyph>), nor does it say
that some metrics must be provided, or even that they are almost always
required.


>
>> Example below.
>>
>> Cheers,
>> Stephen.
>>
>>
>> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xlink="
>> http://www.w3.org/1999/xlink">
>>   <svg xmlns="http://www.w3.org/2000/svg" x="100" y="100" width="400"
>> height="400">
>>     <defs>
>>       <font>
>>         <font-face font-family="xyzzy" units-per-em="8" />
>>         <glyph unicode="1" id="rect1" horiz-adv-x="12" d="M0,0 l10,0
>> l0,10 l-10,0 z" />
>>         <glyph unicode="2" id="rect2" horiz-adv-x="12">
>>           <rect width="10" height="10" x="0" y="0" />
>>         </glyph>
>>       </font>
>>     </defs>
>>     <text x="25" y="25" font-family="xyzzy" stroke-width="1">
>>       12<altGlyph xlink:href="#rect1">A</altGlyph><altGlyph
>> xlink:href="#rect2">B</altGlyph>
>>     </text>
>>   </svg>
>> </html>
>>
>
>
>
> --
> experiri non sit cunnus
>
Received on Wednesday, 19 December 2012 15:41:54 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT