RE: 1.1 2nd edition last call comment : fill-rule on text elements

I agree that fill-rule is part of the graphics state. So is colour.

You can set the colour on the text element and that propagates into
the graphics state being used to draw the text.

The 'G' in SVG stands for Graphics. There is no distinction between
a 'text state' and a 'graphics state'. This is important.

I don't know of any SVG implementation that maintains a 'text state'
as distinct from 'graphics state'. The model is unified.

The debate could go on forever - but SVG is _not_ modal. There is
no notion of text and graphics state being different.

What you suggest is a compartmentalization of the graphics from the
font engine which is typical of limited architectures that assume
the font engine, it's polygon filler and the font cache are somehow
a black box that is separate to the code that is managing the DOM
and the 'pure' graphical elements.

When a proper SVG font implementation forms part of the architecture
as in ASV3 - the glyphs are composed from SVG graphical objects and
so can be animated, coloured, scaled and have their fill-rule propagate
through the <text> element as is shown in _your_ implementation.

The fill-rule being applicable to <text> elements is (1) in a W3C
recommendation; (2) implemented by ASV3, Batik, Vidualize and who
knows how many other viewers and (3) was asked as a question not
as a debate , i.e."... unless we are missing something
" and that
"missing something" was that the fill-rule is applicable when
an SVG engine supports SVG fonts - even Tiny fonts with a single
path since it can self intersect.

Alex

--Original Message--:
>For PDF (and Postscript and, FWIW, Microsoft's XPS) though, fill rule is a Graphic State attribute and NOT a Text State attribute - which is why I said that having it on the <g> in SVG would be the closest thing.  
>
>It's been this way since 1.0 and probably shouldn’t change for that reason alone....
>
>Leonard
>
>-----Original Message-----
>From: Anthony Grasso [mailto:anthony.grasso@cisra.canon.com.au] 
>Sent: Wednesday, August 11, 2010 9:46 PM
>To: Alex Danilo
>Cc: Leonard Rosenthol; Cameron McCormack; Patrick Dengler; SVG Working Group WG
>Subject: Re: 1.1 2nd edition last call comment : fill-rule on text elements
>
>In addition to what Alex said, for Type3 fonts (i.e. glyphs that are defined in 
>PDF), the fill rule can be specified when constructing the paths in the glyph 
>definition.
>
>Alex Danilo wrote:
>> Leonard,
>> 
>>  The example Cameron pointed at displays the correct thing
>> in Adobe ASV3.
>> 
>>  There is pretty clear precedent here in your own company's
>> products, not to mention the excellent reasoning by Cameron.
>> 
>> Alex
>> 
>> --Original Message--:
>>> But couldn't you achieve the same thing by putting the fill-rule on a <g> instead of the <text>?
>>>
>>> -----Original Message-----
>>> From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Alex Danilo
>>> Sent: Wednesday, August 11, 2010 8:11 PM
>>> To: Cameron McCormack
>>> Cc: Patrick Dengler; SVG Working Group WG
>>> Subject: Re: 1.1 2nd edition last call comment : fill-rule on text elements
>>>
>>> +1.
>>>
>>> For the record they render differently in Vidualize as well (i.e. as they should).
>>>
>>> Alex
>>>
>>> --Original Message--:
>>>> Patrick Dengler:
>>>>> We don't believe fill-rule belongs on text elements.
>>>>>
>>>>> http://dev.w3.org/SVG/profiles/1.1F2/publish/painting.html#FillProperties
>>>>>
>>>>> We cannot think of a scenario where this would apply to text.
>>>>>
>>>>> We would like to make this minor adjustment to the spec (remove
>>>>> application to text) unless we are missing something.
>>>> It applies in the case of SVG Fonts, where complex glyphs inherit
>>>> properties from the text content element that references them.  The two
>>>> <text> elements in http://mcc.id.au/2010/text-fill-rule.svg render
>>>> differently in Batik.
>>>>
>>>> -- 
>>>> Cameron McCormack ≝ http://mcc.id.au/
>>>>
>>>>
>>>
>>>
>>>
>>>
>> 
>> 
>
>
>

Received on Thursday, 12 August 2010 02:29:09 UTC