- From: Stephen Chenney <schenney@chromium.org>
- Date: Wed, 19 Dec 2012 10:41:23 -0500
- To: Rick <graham.rick@gmail.com>
- Cc: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAObCcUojDJWB6hTewc1k1r=T193vvYQJXGRWhnFvSu5c=Pu74Q@mail.gmail.com>
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 UTC