W3C home > Mailing lists > Public > www-svg@w3.org > September 2009

Re: Minutes, 26 September 2009 SVG WG F2F - Day 1

From: Alex Danilo <alex@abbra.com>
Date: Mon, 28 Sep 2009 19:14:17 +1000
Message-Id: <TBCOQK.I1BT35PLHAC7@abbra.com>
To: robert@ocallahan.org
Cc: anthony.grasso@cisra.canon.com.au, www-svg@w3.org, public-svg-wg@w3.org
Hi Rob,

--Original Message--:
>On Mon, Sep 28, 2009 at 6:10 PM, Alex Danilo <alex@abbra.com> wrote:
>
>--Original Message--:
>>On Mon, Sep 28, 2009 at 5:45 PM, Alex Danilo <alex@abbra.com> wrote:
>>
>>--Original Message--:
>>>It's not clear to me what was resolved about SVG Fonts, in particular the issue of cloning vs patterns. It sounds like people want 'stroke' and 'fill' properties on <text> to apply to the arbitrary SVG content of a glyph? I honestly don't think that's possible to do in a sane way that works in general.
>>
>>Yes it is. Whether it's difficult in some existing implementations is an orthgonal issue.
>>
>>By cascading the CSS properties from <text> into the font glyph content and hoping that everything works out OK?
>>
>>I previously explained how that completely fails whenever the text might have characters that aren't covered by the SVG Font, because then you can't know which coordinate system will be used to interpret user units in the style of the <text>.
>
>I expect you meant glyphs here. 
>No, I mean the character.

Then you're wrong:-)

Strings of characters need to be mapped to glyphs. Those mappings are 1:1, n:1, 1:m or n:m.

It is the glyphs that are being displayed. So the lack of a 'C' glyph is your issue in this case. The
SVG font is lacking a mapping from the character string 'C' to a glyph used for presentation.

>Perhaps I wasn't clear. Suppose the author writes
><text style="stroke-width:10; font:MySVGFont 100px;">ABC</text>
>Suppose MySVGFont uses the default units per em of 1000, and suppose it includes glyphs for A and B but not C, and the A and B glyphs use <path> elements to render the letters, with the stroke-width inherited from the <text>. Then the stroke used for A and B will be about 1px wide, but the stroke used for C will be 10px wide. The problem is that for characters covered by the SVG font, stroke-width (and everything else that uses user units) is interpreted in the font coordinate system, but for all other characters stroke-width is interpreted in the user unit coordinate system for the <text>.

Thanks for the clarification, and yes you are correct.

There are 2 preferred methods to deal with this:
1) the authoring tool gets it right by making sure the glyphs exist in the SVG font; or preferably
2) the 'missing-glyph' exists in the SVG font.

(2) covers basically all the problems you have with this feature and personally I
prefer that. Authors will see pretty quickly what's wrong.

>So in practice it seems to me that this cascading is only useful when you have a very tight relationship between the producer of the font and the consumer of the font, and in particular the consumer of the font must be able to restrict the characters used in the text --- for example user-provided text is right out. But if there is such a tight relationship between the producer and consumer, why not just put the styling in the font glyph content directly? Are there really significant use cases where there's value in reusing font glyph content, inheriting different styles from different <text> elements, but the font consumer is restricted to static text and has intimate knowledge of the font design details?
>
>Since you've implemented it, maybe you can point us to some examples of people using these features for real projects.

If you want to sign an NDA I'm sure I can show you plenty...

Alex

>Rob
>
>-- 
>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
>
>
>
Received on Monday, 28 September 2009 09:15:00 GMT

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