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

RE: SVG <glyph> element spec

From: David Dailey <ddailey@zoominternet.net>
Date: Fri, 21 Dec 2012 07:16:18 -0500
To: "'Dirk Schulze'" <dschulze@adobe.com>
Cc: "'Erik Dahlstrom'" <ed@opera.com>, <www-svg@w3.org>
Message-ID: <000c01cddf74$fb854cf0$f28fe6d0$@net>
I would suggest
https://www.google.com/#hl=en&safe=off&tbo=d&sclient=psy-ab&q=david+dailey+s
vg+geometric+accessibility&oq=david+dailey+svg+geometric+accessibility&gs_l=
hp.3...5380.16823.0.17361.44.41.1.2.2.0.245.4752.12j28j1.41.0.les%3B..1.0...
1c.1.63cscocq4tQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&bvm=bv.1355534169,d.
dmQ&fp=a5dcfad2a6298f40&bpcl=40096503&biw=782&bih=473 

or
http://www.svgopen.org/2011/papers/43-Geometric__Accessibility/index.html 


The main point to be drawn here is that if authors don't have accessible
ways to make fancy text effects available in accessible formats, then they
will resort to bitmaps and implementers will be liable in lawsuits, since
they have been warned. I'm not a stockholder, so it doesn't much matter to
me, but it might to them.

I exaggerate from time to time, as is well documented, so one needs to read
substance midst humor. There is sufficient substance, though, to document
that without proper ways of embedding graphical effects within text then
zillions of dollars will flow unpredictably, in the traditions of litigious
turbulence and global warming. Certain companies have traditionally
benefited from turbulence, but many have grown weary and grey and are less
likely to thrive on upheaval.

Cheers
D


-----Original Message-----
From: Dirk Schulze [mailto:dschulze@adobe.com] 
Sent: Thursday, December 20, 2012 11:03 AM
To: David Dailey
Cc: Erik Dahlstrom; www-svg@w3.org
Subject: Re: SVG <glyph> element spec


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.

Greetings,
Dirk

> 
> 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 Friday, 21 December 2012 12:16:52 GMT

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