Minutes, 26 September 2009 SVG WG F2F - Day 1

[Anthony Grasso]

http://www.w3.org/2009/09/26-svg-minutes.html

RRSAgent didn't capture the minutes for the last topic. Minutes for the last
topic are attached to the email [26-svg-minutes-last-topic.html].

---


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

26 Sep 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/09/26-svg-irc

Attendees

    Present
    Regrets
    Chair
           Cameron

    Scribe
           Anthony, Cameron, Jonathan

Contents

      * [3]Topics
          1. [4]XSL Report
          2. [5]SVG Fonts
      * [6]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 26 September 2009

    <heycam> Meeting: Mountain View F2F 2009 Day 1

    <anthony_with_mous> Scribe: Anthony

    <anthony_with_mous> ScribeNick: anthony_with_moustache

XSL Report

    <anthony_with_mous> CL: I went to the XSL F2F

    <anthony_with_mous> ... was there for 2 days of the meeting

    <anthony_with_mous> ... main topic of discussion was shapes

    <anthony_with_mous> ... they want to have arbitrary shapes

    <anthony_with_mous> ... or set of shapes

    <anthony_with_mous> ... to any block

    <anthony_with_mous> ... they have page masters then blocks

    <anthony_with_mous> ... and the idea is to add shapes to the blocks

    <anthony_with_mous> ... and idea is the text would fit in the shape

    <anthony_with_mous> ... then flow to the next shape

    <anthony_with_mous> ... by text they mean anything

    <anthony_with_mous> ... tables, lists

    <anthony_with_mous> ... then there are two add ons that make it a
    bit complicated

    <anthony_with_mous> ... tri-tables

    <anthony_with_mous> ... that allow adjustments by varying different
    properties

    <heycam> ScribeNick: anthony_with_mous

    UNKNOWN_SPEAKER: and therefore the text fits with in the shape
    ... and then there's shapes that grow
    ... as the text gets bigger the shape gets bigger in the middle

    DS: It seems to me there's also another case that people want
    ... the first is what you said - copy fitting
    ... it's pretty common that people want to do copy fitting
    ... where they want the text to grow to fit the size of the shape
    ... if you want to have SVG boarders on a CSS block
    ... we don't have any way in SVG saying make this part change
    ... we don't have any way of stating the intentionality of the shape

    AG: Is that still in scope with SVG?

    DS: We could have essentially the pie shape, bars, but not by
    defining them as something with certain behaviours
    ... but more so like the constraint stuff
    ... if we have parts of the shape to grow to meet certain
    constraints

    <ChrisL> notes from the text flowing into shape discussions
    [7]http://lists.w3.org/Archives/Public/www-archive/2009Sep/0056.html

       [7] http://lists.w3.org/Archives/Public/www-archive/2009Sep/0056.html

    DS: SVG wouldn't define a pie chart, they'd define things would grow

    CL: I dropped a link in
    ... and if you scroll down to the bottom
    ... you'll see SMIL
    ... Liam is wondering if you can use SMIL in XSL
    ... I said not really
    ... and suggested a subset of SMIL
    ... the path animation to be exact

    CM: What does path animation represent?

    CL: The main difference here is you're not getting a change over
    time
    ... it represents the shape you want

    CM: The paper you're talking about growing shape to fit text

    <ChrisL> hit the 'pdf' link from
    [8]http://portal.acm.org/citation.cfm?doid=1166160.1166165

       [8] http://portal.acm.org/citation.cfm?doid=1166160.1166165

    CL: In an XSL file the want to have some SVG
    ... have some SVG because you want to draw it or use bits of it but
    don't want to draw
    ... Liam was saying SVG has <defs> element
    ... They'd like to point to gradients
    ... and bits of SVG that's useful
    ... they specifically mentioned doing stuff in Inkscape and dropping
    it in
    ... I gave them an update on the fonts work
    ... there's a public list www-font
    ... and there's a lot of discussion about what do with web fonts
    ... CSS and SVG give you the ability to the open type fonts
    ... which is the same font format as the for sale fonts are sold as
    ... in response to that there were two formats proposed
    ... EOT format
    ... from Microsoft
    ... they have an embedded uri RootString
    ... which people didn't like

    <shepazu> s /EOT/EOT

    CL: the next format was MTX from Agfa
    ... it was objected on the grounds was compression libraries can
    have security problems
    ... so there was case study where gcip was shown to be almost as
    good as MTX particularly with Unicode
    ... as a result there was a proposal for a new font format
    ... a web font format
    ... re-encoding of open type fonts
    ... it was proposed Jonathon Kew
    ... it has a table of sizes and then individual Open Type table
    ... that can be reference
    ... if it's compressed it will say the size when uncompressed

    <heycam> [9]http://mcc.id.au/temp/p3-hurst.pdf -- that's nathan's
    paper

       [9] http://mcc.id.au/temp/p3-hurst.pdf

    CL: there's a specification available and an implementation
    ... that converts both ways to and from open type

    <jwatt>
    [10]http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html -
    that's Jonathan Kew's WOFF spec

      [10] http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html

    DS: He's form SIL and he's interested in the international case
    ... since he has the individual tables zipped
    ... for someone in a place with limited bandwidth it's better then
    for them

    ED: But there's still CPU and memory needed to decompress everything
    ... so there may not be any benefit

    CL: You can download the list tables initially to see which tables
    are needed

    ED: There may not be a big benefit compared to having the whole
    thing zipped due to network latency

    CL: That format was originally called web OTF
    ... there were questions by W3C could use the name
    ... the 3rd draft is called WOFF
    ... Web Open Font Format
    ... There are for formats for doing downloadable fonts
    ... SVG, WOFF, EOT, EOT-lite

    DS: Five
    ... OpenType

    JW: So when you say OpenType you are including TrueType as well?

    CL: Yes OpenType is a super set
    ... my charter proposal will for the formats that are not
    standardised
    ... The thing that people liked was to conform to the spec people
    would have to implement two of the formats
    ... and the bit that I'm going to put in is you have to support
    either the CSS or an XML format
    ... the reason that's interesting and I'm calling it the XML syntax
    and not SVG is because XSL want to use it
    ... in there own name space
    ... they plan to adopt that just as is

    DS: Another reason to make the group is it gets commitment form the
    members to start using the format

    CL: There were some font foundries that were saying we can have
    different licenses for the different formats
    ... so they're happy
    ... one thing with the SVG fonts is they can't do hinting and the
    internationalisation isn't there
    ... one thing we could say for SVG 2.0 is we could say you'd have to
    support WOFF

    CM: Just wondering if you can stick SVG inside something like
    OpenType
    ... the glyph shapes in OpenType are like cubic beziers?

    CL: There are constraints in OpenType fonts

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

    CL: the xsl group is producing a thing called "design notes"

    <ChrisL>
    [11]http://www.w3.org/Style/XSL/Group/2009/03/FPWD-xsl-fo-20.html

      [11] http://www.w3.org/Style/XSL/Group/2009/03/FPWD-xsl-fo-20.html

    CL: they had a piece about colour that was drawn from svg print
    ... and the only bit it really had was the device specific colour
    stuff

    <shepazu>
    [12]http://people.mozilla.com/~jkew/woff/woff-spec-latest.html

      [12] http://people.mozilla.com/~jkew/woff/woff-spec-latest.html

    CL: they were getting ready to publish this, and almost about to
    publish
    ... i offered to rewrite the colour section

    <ChrisL>
    [13]http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2009Sep/0033.h
    tml

      [13] http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2009Sep/0033.html

    CL: i explained the differences between svg colour and svg print,
    the current state of things, and proposed wording which they agreed
    to
    ... so it's in the spec now
    ... i gave them some wording, assuming you adopt all features from
    svg color, which you would probably select from
    ... and i suggested some syntax that seemed to fit with their style
    ... and they accepted the proposal as is

    AG: so you always have to place an rgb falback

    CL: yes, srgb fallback
    ... some others wanted cmyk fallback, but we ended up with just srgb
    fallback

    CM: why is the "ICC" in capitals there?
    ... are xsl properties case sensitive?

    CL: yes they are
    ... i don't mind if they change that
    ... we got one piece of feedback on this
    ... in the design notes it says "Four new functions are added to
    support device-dependent color"
    ... the HP person wanted "device n channel" instead of "device multi
    channel"
    ... the other change he wanted was a uri or reference to a block of
    data, since that's the way they do it, of describing the colors in
    the printer
    ... we were vaguely aware that's what they did, but we didn't have
    concrete information

    <fat_tony> Scribe: Anthony

    <fat_tony> ScribeNick: fat_tony

SVG Fonts

    CM: Robert wonders what the use cases for SVG Fonts are

    CL: I sent a reply
    ... with a bunch of use cases
    ... and he replied to say that was useful

    CM: What I'd like to know is
    ... what features of SVG Fonts can you not with regular OpenType
    fonts are used
    ... and which of them are basically an abuse of SVG Fonts to get
    some nifty behaviour

    CL: The only abuse that I'm aware of is wishing SVG had a Y-Up
    coordinate system

    ED: I've seen people using fancy stroking for effects

    <ed> ...using glyphs in svg fonts

    DS: Which ones are used?

    CM: Yes and which ones are not

    DS: Hard to know at this point
    ... because ASV supported them
    ... and it's older content
    ... I'd like to be able to use SVG Fonts for doing complex shapes
    for illuminated fonts

    CL: You can do RT stuff
    ... multi-coloured stuff
    ... anything you can draw you can make it into a glyph

    <shepazu>
    [14]http://www.alifetimeofcolor.com/study/images/illum_manuscript_l.
    jpg

      [14] http://www.alifetimeofcolor.com/study/images/illum_manuscript_l.jpg

    CL: if you give people a way to draw pictures and wrap it as text

    <shepazu> [15]http://www.graphic-design.com/Type/caps/CapB.jpg

      [15] http://www.graphic-design.com/Type/caps/CapB.jpg

    CL: people will eventually put pictures as text

    DS: [talks about second link]

    CM: What happens when you fill SVG Font text?

    CL: We added something specific for just the 'd' attribute

    DS: You mean for Tiny?

    CL: Yes

    ED: Say you wanted to fill what was specified in the 'd' attribute
    ... if you wanted to fill the path with something with full fonts
    you wouldn't be able to do that

    CL: Suppose you do a font like Jurassic Park your path on the outer
    thing with red bits
    ... and do that for loads of text
    ... for each occurrence of the character you have a hidden tree
    ... multiple copies of this arbitrary content

    ED: I'd suggest it inherits from document tree

    CL: So you mean like a current colour?

    ED: Similar
    ... the question is what properties you want there
    ... and applies

    CL: Colour

    ED: Fill, stroke
    ... that would be possible and would make it much simpler

    <ChrisL> They tend to be used for short, decorative, one-off text
    strings. Kerning, glyph shapes may be modified for the one pieve of
    artwork.

    <ChrisL> They can be used for less common languages.

    <ChrisL> The glyphs don't have the same constraints that TT/OT
    glyphs have, in terms of placement of control points, winding rule,
    avoidance of overlap and self-intersection. They can mix cubics,
    quadratics, and straight line segments as needed.

    <ChrisL> In other words, if you can draw it, you can make it a
    glyph. And the SVG engine can already render it because it already
    knows about paths, fill, stroke, opacity etc.

    <ChrisL> Of course, the temptation is to just draw something which
    looks, visually, like text. SVG gives the option to make it real,
    searchable, accessible and updatable text, for very little more
    effort.

    ED: I guess it would be nice to style the colours in the text based
    on where they are used

    <ChrisL> from dev-tech-svg@...

    CM: Some body to suggested to solve that use case
    ... you could stick an attribute on graphical content?

    CL: Why would do that?

    JW: I have a reason for not doing that
    ... is you can't select it
    ... what if I want to select one word out of three word heading?

    DS: You could essentially do it as a ligature

    JW: It makes it different to the rest of the text behaves

    CM: You could break it down into logical blocks, words, sections,
    letter

    JW: You can do it as separate words or text
    ... then you're saying this graphic is this word
    ... then how do you join them together
    ... so when you search for it, it is found

    DS: Logical and visual order can be abused even with regular text

    CL: I was remembering that Vincent Hardy asked what's the use case
    for all this SVG stuff
    ... why not use a single path
    ... he said unless we do it that way SVG will not be used
    ... his argument was persuasive
    ... then the guy from Kodak
    ... said we've got a use case that can only done in SVG and not in
    True Type
    ... after a while Vincent Hardy did see the use cases and started
    making content

    DS: [Draws diagram on board]
    ... you can't do that as an SVG font

    ED: Yes you can

    DS: This is something that is a one off thing
    ... and you don't want to spend the time and energy adjusting
    everything
    ... to get it readable

    CL: It would be work
    ... I agree
    ... but it could be done

    DS: My point is this is something you can not do with OpenType
    ... how is this different form a ligature

    <anthony> JW: ROC is asking for give me the use cases

    CL: He's collecting the use cases
    ... and Alex D has chipped in with support

    JW: It's obvious for the use cases that the majority of them are
    catered for by WOFF
    ... ROC just wants to know have we pretty much covered all the cases
    that people want to handle
    ... and whether it should be put as a priority
    ... That's what I'd like to hear is the use cases
    ... you have all this power to make anything a glyph

    <ChrisL> typography teaching with serifs, verticals

    JW: but I want to see why people want to do things that can't be do
    in WOFF or OpenType

    <ChrisL> glyphs with icicles in blue-and-white, with font whatever
    color is wanted

    <ChrisL> nimated drawing fonts for chinese

    DS: I want to do a header and it has blue with icicles

    <ChrisL> scripted distressed fonts

    JW: I think we should try and collect a page
    ... with graphical examples

    <ChrisL> illuminated glyphs

    <ChrisL> jurassic park font with red inlay

    DS: People when doing layouts with glyphs
    ... [draws a diagram with Oprah W]

    JW: You'd want examples that don't raise too many examples
    ... that drawing raises too many questions

    <heycam> Scribe: Jonathan

    <heycam> ScribeNick: jwatt

    DS: we should highlight what SVG fonts are good for

    s/too many exmples/too many distracting questions/

    <fat_tony> Scribe: Anthony

    <fat_tony> ScribeNick: fat_tony

    <ChrisL> Erik van Blokland

    <ChrisL>
    [16]http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html

      [16] http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html

    <ChrisL> [17]http://www.robofab.com/

      [17] http://www.robofab.com/

    <ed> [that is in relation to SVG Fonts having a DOM and being
    editable that way clientside]

    <ChrisL> [18]http://www.fontlab.com/python/

      [18] http://www.fontlab.com/python/

    <ChrisL> robofog [19]http://typophile.com/node/13759?

      [19] http://typophile.com/node/13759?

    CM: So out of this we need use case on a Wiki pages
    ... so who is going to do this?

    JW: Whoever has examples or ideas of what people want to do
    ... so you could animate the stroke order of Asian characters
    ... for a tutorial

    AG: Someone will have to go through the minutes and put examples up
    on the wiki

    <jwatt> put use case ideas here:
    [20]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Font_Use_Cases ?

      [20] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Font_Use_Cases

    JW: Is that URL ok?
    ... problem is the interest group can't edit that

    AG: so if we want input from them that's no good

    <jwatt> ok, so
    [21]http://www.w3.org/Graphics/SVG/IG/wiki/SVG_Font_Use_Cases then?

      [21] http://www.w3.org/Graphics/SVG/IG/wiki/SVG_Font_Use_Cases

    <jwatt> the IG wiki is open to the public to make accounts, so
    anyone could add their ideas

    AG: I think we should get the SVG IG to give us use cases

Summary of Action Items

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [22]scribe.perl version 1.135
     ([23]CVS log)
     $Date: 2009/09/26 22:39:27 $
      _________________________________________________________

      [22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [23] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [24]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/but/... by/
Succeeded: s/they have/SVG has/
Succeeded: s/form/from/
Succeeded: s/ whole thing zipped/ whole thing zipped due to network lat
ency/
Succeeded: s/EOT-lite/EOT/
Succeeded: s/test/text/
FAILED: s/too many exmples/too many distracting questions/
Succeeded: s/line order/stroke order/
Found Scribe: Anthony
Found ScribeNick: anthony_with_moustache
WARNING: No scribe lines found matching ScribeNick pattern: <anthony_wi
th_moustache> ...
Found ScribeNick: anthony_with_mous
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Anthony
Found ScribeNick: fat_tony
Found Scribe: Jonathan
Found ScribeNick: jwatt
Found Scribe: Anthony
Found ScribeNick: fat_tony
Scribes: Anthony, Cameron, Jonathan
ScribeNicks: anthony_with_moustache, anthony_with_mous, heycam, fat_ton
y, jwatt

WARNING: No "Present: ... " found!
Possibly Present: AG CL CM ChrisL DS JW ScribeNick anthony anthony_with
_mous ed eseidel eseidelDesk fat_tony fat_tony_ heycam joined jwatt she
pazu svg trackbot
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Found Date: 26 Sep 2009
Guessing minutes URL: [25]http://www.w3.org/2009/09/26-svg-minutes.html
People with action items:

      [25] http://www.w3.org/2009/09/26-svg-minutes.html

    End of [26]scribe.perl diagnostic output]

      [26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

SVG Working Group Teleconference

26 Sep 2009

See also: IRC log

Attendees

Present

Regrets

Chair

Cameron

Scribe

Anthony

Contents

• Topics
  1. Ambiguity in glyph element definition
• Summary of Action Items

---

<trackbot> Date: 26 September 2009

<heycam> Meeting: Mountain View F2F 2009 Day 1

<scribe> Scribe: Anthony

<scribe> ScribeNick: fat_tony

Ambiguity in glyph element definition

DS: What if you have a completely different thing like script

CM: That's the example that Erik gave

CL: In particular the way the script being handled is weird

DS: What about CSS?

CL: It has parsing rules that allows you to skip over it
... [reads section of spec out]

DS: That's fine looks good to me

ED: I'm concerned that's going to break things in the future
... because it looks like we are planning to change SVG Fonts anyway
... we also discussed how things inherit into it
... I guess we haven't decided on how it is going to work

DS: You did talk about what sorts of changes you want to make?

JW: For restricting content what would we restrict?

CL: Unless we restrict it to zero
... the errata I just stuck in doesn't change anything

DS: Chris's change just clarifies the spec
... it's not changing anything
... if we want to change anything in 2.0
... then that's fine

ED: Just sounds weird to me
... but if that's the way it's suppose to work
... it's not going to change what we do

CL: I don't see how it's different from a bunch of <use> elements
... both of them say they create anonymous shadow trees

ED: The wording for the way it behaves like a cloning thing is not good
... I agree with what ROC says

JW: Does batik render anything other than the 'd' attribute

CM: Yes

JW: Inheritance thing?

CM: Not sure

JW: Say I have two <tspans> in a text thing that's using a font
... those two <tspans> might have different styling
... and the same glyph
... if you do shadow trees then you need to do different styling

ED: I was thinking about a font that could be made on both old and new user agents
... in some situations there might be a case where you want to provide a completely different glyph
... I can think of other ways of doing it

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Fonts

ED: So these are the properties that would inherit by default?

JW: Unless you tried to stop them

CM: So is this the list of all inherited properties minus the font ones?

JW: I wasn't trying to create a complete list though

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_Fonts_Inheritance

JW: the font element should be self contained
... if I copy and paste a font that has a gradient
... reference, then it will break

CL: But how is that different from a group

JW: I think of fonts as more self contained things

<ChrisL> They can be coded like that. Its authoring advice

DS: Unless there is a optimisation advantage

JW: It would be more overhead to restrict it

ED: So I'm not objecting to the change anymore

CL: I propose removing within an SVG document fragment part

<ed> xlink:href for tref says:

<ed> A URI reference to an element/fragment within an SVG document fragment whose character data content shall be used as character data for this 'tref' element.

<ed> change to:

<ed> A URI reference to an element whose character data content shall be used as character data for this 'tref' element.

RESOLUTION: We agree to remove the restriction of tref pointing to only an SVG document fragment

ED: So I put fill and stroke-width with on a glyph and it didn't affect the glyph
... I guess it depends what type of element the glyph is

CM: I don't think it's good to treat it differently

<ed> if fill and stroke-width is put on a <text> element then it does affect the rendered text

<ed> so the same for svg fonts as for any other type of font

CM: But does it do it in the coordinate system of the glyph?

ED: I don't think so

<ed> the inheritance rules are slightly different for 'd' and child content on <glyph>

<ed> for 'd' attributes particularly: "The resulting, transformed path specification is rendered as if it were a 'path' element, using the styling properties that apply to the characters which correspond to the given glyph, and ignoring any styling properties specified on the 'font' element or the 'glyph' element."

Summary of Action Items

[End of minutes]

---

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $

[Robert O'Callahan-3]

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.

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]

[Alex Danilo]

Hi Roc,

--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.

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]
>
>
>

[Robert O'Callahan-3]

On Mon, Sep 28, 2009 at 5:45 PM, Alex Danilo <alex@...> 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>.

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]

[Alex Danilo]

Hi Rob,

--Original Message--:

>On Mon, Sep 28, 2009 at 5:45 PM, Alex Danilo <alex@...> 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.

I've implemented this twice in the past and yes the cascade should propagate into the glyphs for
drawing them for the 'instance' of the glyph. So effectively it's like a clone but there is no
need to actually clone if the model is right.

If you hit glyph that isn't part of the SVG font and have to switch to a system font then
you do so on a per-glyph basis. It isn't that hard.

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]
>
>
>

[Robert O'Callahan-3]

On Mon, Sep 28, 2009 at 6:10 PM, Alex Danilo <alex@...> wrote:

--Original Message--:

>On Mon, Sep 28, 2009 at 5:45 PM, Alex Danilo <alex@...> 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.

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>.

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.

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]

[Alex Danilo]

Hi Rob,

--Original Message--:

>On Mon, Sep 28, 2009 at 6:10 PM, Alex Danilo <alex@...> wrote:
>
>--Original Message--:
>>On Mon, Sep 28, 2009 at 5:45 PM, Alex Danilo <alex@...> 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]
>
>
>

[Robert O'Callahan-3]

On Mon, Sep 28, 2009 at 7:14 PM, Alex Danilo <alex@...> wrote:

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.

That's what I mean by the SVG font lacking coverage for character 'C'.

>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.

In both cases you're assuming completely static text. But OK.

Actually I wonder how 'missing-glyph' is supposed to interact with the font matching specified by CSS. It appears that the SVG 'font-family' property is normatively defined by CSS:
http://www.w3.org/TR/SVG/text.html#FontPropertiesUsedBySVG
When a CSS user-agent can't find glyphs for a character in the font(s) specified by the author in 'font-family', the CSS font matching algorithm requires the user-agent to locate a font that does support the character, searching every font on the user's system if necessary:
http://www.w3.org/TR/CSS2/fonts.html#algorithm

Does SVG intend to alter the behaviour of the CSS font matching algorithm when an SVG Font with 'missing-glyph' is specified in 'font-family'? I can't find anything in the spec to confirm this. If so, in what manner?

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]

[Alex Danilo]

Hi Rob,

--Original Message--:
>On Mon, Sep 28, 2009 at 7:14 PM, Alex Danilo <alex@...> wrote:
>
>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.
>
>That's what I mean by the SVG font lacking coverage for character 'C'.

Sure, understood. Just to be clear, the actual match is on a character string
so in this case the string consists of just one character.

>
>>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.
>
>In both cases you're assuming completely static text. But OK.
>
>Actually I wonder how 'missing-glyph' is supposed to interact with the font matching specified by CSS. It appears that the SVG 'font-family' property is normatively defined by CSS:
>http://www.w3.org/TR/SVG/text.html#FontPropertiesUsedBySVG
>When a CSS user-agent can't find glyphs for a character in the font(s) specified by the author in 'font-family', the CSS font matching algorithm requires the user-agent to locate a font that does support the character, searching every font on the user's system if necessary:
>http://www.w3.org/TR/CSS2/fonts.html#algorithm
>
>Does SVG intend to alter the behaviour of the CSS font matching algorithm when an SVG Font with 'missing-glyph' is specified in 'font-family'? I can't find anything in the spec to confirm this. If so, in what manner?

A very good question indeed.

The WG needs to consider that, as it's a good point.

My off the cuff reaction would be that the missing-glyph is kind of a regular expression
wild-card that would block the CSS matching search. That seems to be the most
logical choice given the 5 seconds I've thought about it. I'd expect that in the absence
of the missing-glyph element, then the CSS matching algorithm would apply.

But that comment is a cursory view that's likely got holes in it.

Cheers,
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]
>
>
>

[Chris Lilley]

On Monday, September 28, 2009, 2:59:53 PM, Robert wrote:


ROC> Does SVG intend to alter the behaviour of the CSS font matching
ROC> algorithm when an SVG Font with 'missing-glyph' is specified in
ROC> 'font-family'?

No.

And specifically, its not 'a match'. Which is why it has a different element name, to indicate that its not a regular glyph.

It just provides a glyph that could be used for characters that are not covered. However, other fonts in the font-family list, or the generic font family, or a system fallback font, might have coverage. And even if they do not, the actual 'missing glyph' might be drawn from the svg font, or drawn from any other font n the list (commonly, the last one on the list).

ROC>  I can't find anything in the spec to confirm this. If so, in what manner?

Did you find anything which implies that SVG alters the font matching algorithm?



--
 Chris Lilley                    mailto:chris@...
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

[Robert O'Callahan-3]

On Tue, Sep 29, 2009 at 5:25 AM, Chris Lilley <chris@...> wrote:

It just provides a glyph that could be used for characters that are not covered. However, other fonts in the font-family list, or the generic font family, or a system fallback font, might have coverage. And even if they do not, the actual 'missing glyph' might be drawn from the svg font, or drawn from any other font n the list (commonly, the last one on the list).

ROC>  I can't find anything in the spec to confirm this. If so, in what manner?

Did you find anything which implies that SVG alters the font matching algorithm?

No. I observed that if the CSS matching algorithm is not altered, then (assuming the user has local fonts with broad Unicode coverage) the 'missing-glyph' from an SVG font is very unlikely to ever be used, so the feature has very little value. I also noticed that Opera uses the missing-glyph when an SVG Font is specified in 'family-name', without performing CSS font matching, so I thought perhaps I'd missed something in the spec.

Also, Alex thought the use of 'missing-glyph' would prevent the confusion over coordinate systems that I mentioned. But given CSS font matching will be performed, it actually won't make any difference.

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]