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

Re: SVG <glyph> element spec

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 20 Dec 2012 08:02:50 -0800
To: David Dailey <ddailey@zoominternet.net>
CC: Erik Dahlstrom <ed@opera.com>, "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <0D35907E-96EA-4C72-9258-78BCB0F2BA62@adobe.com>

On Dec 20, 2012, at 2:45 AM, "David Dailey" <ddailey@zoominternet.net> wrote:

> The Adobe ASV viewer supports arbitrary content inside <glyph>. Please let me know if a proposal to drop support for colors and other non-path content inside <glyph> gains traction. Emoji contain color as a semantic aspect of Unicode defininitions of characters, and as those who saw our presentation in Boston about geometric accessibility, accessibility to special textual affects is permanently impaired if SVG is crippled in this way.
> It will be a good opportunity for me to learn to file formal objections through the W3C process, and I will be certain to do so!

Is there a recording of the presentation? Or do you have a link to the documentation? This sounds like you are addressing pure visual aspects of styling.

For WebKit we decided not to support arbitrary shapes because of different security considerations.


> Cheers
> David
> -----Original Message-----
> From: Erik Dahlstrom [mailto:ed@opera.com] 
> Sent: Thursday, December 20, 2012 5:33 AM
> To: www-svg@w3.org
> Subject: Re: SVG <glyph> element spec
> On Thu, 20 Dec 2012 08:37:44 +0100, Dirk Schulze <dschulze@adobe.com>  
> wrote:
>> 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.
> I think Batik and the viewer from Abbra are the only implementations I've  
> used that supports (probably a subset of) full SVG Fonts, as in child  
> elements in <glyph>. AFAIK no web browsers support arbitrary child  
> elements in <glyph>.
> -- 
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
Received on Thursday, 20 December 2012 16:03:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:30 UTC