W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2011

Minutes, 8 December 2011 SVG WG telcon

From: Chris Lilley <chris@w3.org>
Date: Thu, 8 Dec 2011 22:35:45 +0100
Message-ID: <879612796.20111208223545@w3.org>
To: SVG WG <public-svg-wg@w3.org>
Hello SVG WG,

Minutes in html at

and below as text

                   SVG Working Group Teleconference

08 Dec 2011


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0100.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/12/08-svg-irc


          [IPcaller], ed, heycam, Tav, cyril, Doug_Schepers, ChrisL,




     * [4]Topics
         1. [5]Sydney f2f
         2. [6]text metrics with display: none
         3. [7]ignoring trailing semicolons
         4. [8]jltf draft review request
         5. [9]function based input for animation
         6. [10]mesh gradients
     * [11]Summary of Action Items

   <trackbot> Date: 08 December 2011


     [12] http://blogs.msdn.com/b/ie/archive/2011/12/07/moving-to-standards-based-web-graphics-in-ie10.aspx

   <heycam> cool!

   <Tav> cool+!

   <scribe> scribenick: ChrisL

   <scribe> chair: heycam

Sydney f2f

   cc: updated wiki page, location is the novotel


     [13] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012

   cyril: room for 18 people and good connection, checking on vpn and
   when the room is open. Should be 8am to 7pm to give us flexibility

   <heycam> [14]https://www.w3.org/2002/09/wbs/19480/SydneyF2F2012/

     [14] https://www.w3.org/2002/09/wbs/19480/SydneyF2F2012/

   cyril: tea, coffee, and lunch included. Three on-site restaurants.
   Booked weds-sat inclusive. Rate at the hotel for rooms, shortly

   shepazu: conflicting audio wg meeting, might prevent me from

   heycam: is this the w3c travel restriction?

   shepazu: w3c nowadays does not like sending two staff contacts to a
   group. But this makes less sense if the staff contacts are active
   technicalcontributors rather than just process guardians
   ... will sort out soon whether i can attend

   ChrisL: should be there, doctor permission, working on travel plans.
   responded to survey

   cyril: nothing else i can think of - if there are questions please
   ... vegetarians and other dietary restrictions taken into account
   for lunch

text metrics with display: none

   <heycam> [15]http://www.w3.org/mid/4ED2EB0B.3050701@mozilla.com

     [15] http://www.w3.org/mid/4ED2EB0B.3050701@mozilla.com

   heycam: brian birtles brought it up. Behaviour of svg dom text
   methods to get number of characters, extent, points along a line of
   ... and whether they count glyphs with display: none. In some cases
   the imps count characters in the dom
   ... replied with my opinion

   <heycam> ack

   <heycam> ack

   <heycam> CL: should be simple, we have definitions for what
   visibility:hidden and display:none means

   <heycam> … also we have a difference between characters in backing
   store and what's displayed

   <heycam> … everything that's display:none isn't in the render tree,
   which you must be doing if you're measuring the text, they're not
   there, they don't have a position

   <heycam> … that's separate from indexing into the characters

   heycam: agree it should be clear from the spec
   ... indexing should be based on characters in the backing store.
   Other imps dfo not count the display: none characters for indexing

   <ed> getNumberOfChars definition from 1.1SE [[ Returns the total
   number of characters available for rendering within the current
   element, which includes referenced characters from ‘tref’ reference,
   regardless of whether they will be rendered. ]]

   heycam: there is an issue of what to return if you ask about
   characters that are not rendered. need to decide on 0, or NaN or

   cyril: it can be hard to know if the font engine is only activated
   when displayingcharacters

   heycam: can depend on glyph shapingand substitution. metrics only
   returned on characters that are displayed


     [16] http://www.w3.org/TR/SVG11/text.html#__svg__SVGTextContentElement__getNumberOfChars

   ChrisL: I see erik posted about what 1.1se says

   heycam: Its not inconsistent

   ChrisL: But for the actual position along a path, it does depend on
   display: none

   heycam: wondered about displaying the position where it *would* be
   ... but its not the right way as it depends on what that character
   ... and you want to avoid the layout of the text
   ... so its better to throw an exception or return NaN

   ChrisL: which is better, NaN or exceptions?

   heycam: in the past we have not used NaN. Either is better than
   returning zero

   ChrisL: exceptions can return information on why its not displayed -
   display: none or off the end of the path or clipped or whatever.
   more extensible also

   heycam: true

   ChrisL; Does the text need changes?

   heycam: yes, display: none not handled. indexing is covered but
   could be clearer

   ed: if its called on textPath or tspan, indexes are from start of
   that element not the start of the <text> element

   ChrisL: so we have a rationale on how it should work, we now need to
   check the text, make changes, add examples and tests
   ... if these apply to 1.2SE should we add errata?

   shepazu: no, a lot of work

   ChrisL: yes, if it applies to 1.1

   shepazu: remind people how long it took for 1.1se

   heycam: mostly because it was a whole new edition, not justerrata

   ChrisL: mainly the delay was getting implementations to pass

   shepazu: fine to document errata for bugs
   ... want to avoid refactoring

   ChrisL: (scribe missed)

   heycam: for this particular issue its a sentence or two
   ... decide on case by case basis depending on effort needed to

   <scribe> ACTION: cameron to propose wording changes and write tests
   for text metrics with display: none [recorded in

   <trackbot> Created ACTION-3180 - Propose wording changes and write
   tests for text metrics with display: none [on Cameron McCormack -
   due 2011-12-15].

   heycam: will reply on thread to update based on this discussion

ignoring trailing semicolons

   <heycam> [18]http://www.w3.org/mid/4ED303C7.4010901@mozilla.com

     [18] http://www.w3.org/mid/4ED303C7.4010901@mozilla.com

   heycam; also from brian, this is for smil animation. some content on
   web uses semicolon termination rather than separation so the lest
   thing in the attr is a semicolon

   scribe: some implementations accept and ignore it, some consider it
   invalid. brian proposes to allow ignoring

   shepazu; recall this in 1.1 timeframe, i was on Dr Olaf's side and
   matching smil was important. Since changed opinion and think
   pragmatic choice is to be inconsistent to maximise compat with
   implementations and content

   heycamq: my view also

   <heycam> CL: I want to distinguish ignoring a trailing semicolon and
   ignoring null values in the middle of a list

   <heycam> … dr olaf's point is that you can have null values and they
   can be meaningful, and we shouldn't disallow that

   <heycam> … if a null value at the end doesn't make a difference just
   ignoring it is a workable solution

   heycam: proposal was just to allow a trailing semicolon and if you
   have a list of strings then you need an extra semicolon at the end
   to distinguish that case

   shepazu: most real world cases are not expecting a trailing
   semicolon to be a null value
   ... most people dont understand the smil enough. common in aloop in
   script to just output semicolon always
   ... and also implementatins don't do that

   heycam: much more common
   ... quirky part is requiring ;;; when you really do want a null last

   shepazu: wish we could search web to see the actual usage

   ed: requiring an extra semicolon is not that bad

   heycam: we shoud reuse smil unless we have a reason not to , but
   should not let it constrain us when we need to improve and clarify

   <scribe> ACTION: erik to reply on trailing semicolon thread
   [recorded in

   <trackbot> Created ACTION-3181 - Reply on trailing semicolon thread
   [on Erik Dahlström - due 2011-12-15].

jltf draft review request

   <heycam> [20]http://www.w3.org/mid/4ED5148B.6030100@w3.org

     [20] http://www.w3.org/mid/4ED5148B.6030100@w3.org

   <heycam> CL: I had a look at this

   <heycam> … I was familiar with the previous one

   <heycam> … they've added a new section

   <heycam> … in terms of SVG, given that currently SVG doesn't
   understand how to so more than one line of text -- it doesn't do
   layout, or page layout -- and most of this is layout of formatted
   text on a page

   <heycam> … the affect on SVG is minimal

   <heycam> … it does have things about character classes, which might
   affect us

   <heycam> … so we neither violate it or prohibit it, it doesn't
   affect us

   <heycam> … as soon as we get wrapping text, 1.2T textArea or HTML
   text in a box

   <heycam> … there's nothing about ligature formation in there

   <heycam> … didn't see anything about :first-letter, which would
   affect us

   <heycam> … so from a quick pass looking at it, I don't think there's
   much impact on SVG directly

   heycam: little on layout requirements in figures

   <heycam> CL: there is some information about figures, but it's mroe
   about layout of figures/captions in the document

   ChrisL: yes, nothing on callouts in diagrams
   ... wonder if this is missing because there is nothing there or
   because they didn't consider it

   shepazu: its mainlky informed by traditional print media
   ... example, us uses a green check(tick) for ok and red cross fro

   in japan its a check for wrong and a circle for ok

   scribe: there are iconographic conventions that differ in japan.
   could be in their scope

   ChrisL: we should reply asking them to cover this

   shepazu; and we cn also say that we integrate the things that affect
   layout via css

   <scribe> ACTION: chris respond to jlft review request [recorded in

   <trackbot> Created ACTION-3182 - Respond to jlft review request [on
   Chris Lilley - due 2011-12-15].

function based input for animation


     [22] http://www.w3.org/mid/001301ccad4b$c6355c40$52a014c0$@net

   heycam: this one we asked david for clarificationand he replied
   ... he wants animate motion but targetting explicit attributes not
   the transform

   <heycam> <animatePath xlink:href="#curve1" xattribute="cx"

   <heycam> <animatePath xlink:href="#curve2" xattribute="rx"

   heycam: he wants to take x and y positions from the curves and apply
   them to particular attributes

   <heycam> CL: this reminds me of a comment we got a long time ago,
   whose profession was an animator

   <heycam> … they wanted smooth curves through things, and you
   couldn't do much without decomposing beziers into separate

   <heycam> … I'm wondering if this feature would let us do what he

   <heycam> … he wanted to be able to animate any attribute as a smooth
   function, rather than giving a pointwise list of values and going
   dot to dot

   heycam: can get this if you animate with a list of values and use
   ... animate motion gives you an essy way to do (paced animation)

   <heycam> CL: if you use keySplines, that only gives you smoothness
   across a single pair of values, not curve continuity

   <heycam> … you would have to calculate it yourself

   <heycam> … and I'm not sure you can in all cases

   <heycam> … you're looking for tangent continuity where the pieces

   <ed> note that some svg implementations allow keySpline values
   outside the 0..1 range

   <heycam> … we've already decided to include catmull rom curves,
   which give you curve continuity

   ChrisL: yes its valuable for overshoot

   heycam: yes for the controlpoints, not sure about the curves

   ed: proposal is not much harder than what we already have, it
   introduces no new element-to-element dependencies
   ... so this is not so hard to implement
   ... and if its useful then we could investigate more

   <heycam> CM: I want to be slightly more convinced about use cases,
   but I can believe after this discussion that there are some

   <heycam> DS: can we say we'll look into variations on this theme for
   SVG2, without going in to too much detail?

   <heycam> CM: I think that's fine


     [23] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Function-based_input_for_.3Canimate.3E

   <scribe> scribenick: ChrisL

   resolution: we will support path-based animations of pairs of

   <scribe> ACTION: erik to reply to david about function-based
   animation [recorded in

   <trackbot> Created ACTION-3183 - Reply to david about function-based
   animation [on Erik Dahlström - due 2011-12-15].

   cyril: are these restricted to animating attributes on the same

   ChrisL: no

   heycam: consistent with existing limitation as you can have two
   animations, one for x and one for y

mesh gradients


     [25] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2GradientsComments


     [26] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2GradientsComments

   cyril; reviewed this and was reading a paper explaining gradient
   mesh technologies

   scribe: played in inkscape and illustrator which behave differently
   ... illustrator shows four patches for editing, but they dont
   produce that rendering.
   ... because they use bilinear interpolation between vertices, not
   across patches

   cyril: illustrator is generating hundreds of patches to give a
   smooth result
   ... this difference is confusing for people
   ... in tav's example he uses degenerate meshes with coincident
   points, to loose the bilinear interpolation

   tav: forgot how i had done it and ran into the same problem as you

   cyril: wanted it to be clear that what we have now cannot make
   smooth gradients across patches. paper linked from my page describes
   another type with color derivatives at mesh points
   ... paper says that illustrator and corel draw estimate these
   derivatives based on a cubic interpolation of the color between two
   mesh vertices
   ... so you have white and red, and you assume a cubic spline
   interpolation, use that as a derivative for the color
   ... want to propose changes to the requirements document, add to
   tensor product meshes to list of existing technologies
   ... and decide if we want those as well

   <heycam> ack

   <heycam> CL: once you have multiple patches, sometimes you want a

   <heycam> … if you think about it as a 2D curve, sometimes you want
   them to be continuous, sometimes a sharp change, sometimes

   <heycam> … you tend to do that by duplicating control points

   <heycam> … first I agree we want smooth interpolation

   <heycam> … but you don't always want it

   <heycam> … at some extent we're comfortable adding this because
   cairo etc. supports it

   <heycam> … is there support in underlying libraries for these more
   complicated patches?

   <heycam> … or can you split them up programmatically so the author
   doesn't need to do it, and it doesn't need to be in the DOM?

   cyril: agree we need both smooth and sharp interpolation
   ... also agree its interesting to see what the underlying libraries

   tav: adobe pdf and postscript only support tensor, whichis coons
   with one additional control pooint

   cyril: yes there is a difference between what illustrator supports
   and what pdf/ps support

   tav: how often does this bite you? in black and white its obvious
   but when drawing natural objects how often do you meet this?

   cyril: graphic designers want control over the transition, smooth to

   tav: can we rely on authoring software to generate this?

   <heycam> CL: it's not better if documents need to include many many
   small patches

   cyril: not asking for the svg to be changed

   <heycam> CL: we're also adding catmull rom, perceptually linear
   colour spaces, those two things will help with smoother gradients

   <heycam> … if the coons patches are doing bilinear interpolation,
   can we just say that it uses bicubic? taking two patches into

   <heycam> … would that totally break what libraries have?

   tav: libraries now create each patch separately

   <scribe> ACTION: cyril to add Tensor-product patch meshes to the
   list of technologies in the requirements document [recorded in

   <trackbot> Created ACTION-3184 - Add Tensor-product patch meshes to
   the list of technologies in the requirements document [on Cyril
   Concolato - due 2011-12-15].

   heycam: smooth gradients are a should, if support mens native
   support in the language, we might decide not to based on library

   cyril: and possible fallback to authoring tools
   ... wil ledit the rwquirements document

   <scribe> meeting: SVG WG telcon

Summary of Action Items

   [NEW] ACTION: cameron to propose wording changes and write tests for
   text metrics with display: none [recorded in
   [NEW] ACTION: chris respond to jlft review request [recorded in
   [NEW] ACTION: cyril to add Tensor-product patch meshes to the list
   of technologies in the requirements document [recorded in
   [NEW] ACTION: erik to reply on trailing semicolon thread [recorded
   in [31]http://www.w3.org/2011/12/08-svg-minutes.html#action02]
   [NEW] ACTION: erik to reply to david about function-based animation
   [recorded in

   [End of minutes]  

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Thursday, 8 December 2011 21:35:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC