SVG Working Group Teleconference -- 08 Dec 2011

<trackbot> Date: 08 December 2011

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

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

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 ask
... vegetarians and other dietary restrictions taken into account for lunch

text metrics with display: none

<heycam> 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 text
... 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> 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 what

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

<ed> 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 is
... 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 backport

<scribe> ACTION: cameron to propose wording changes and write tests for text metrics with display: none [recorded in http://www.w3.org/2011/12/08-svg-minutes.html#action01]

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

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 things

<scribe> ACTION: erik to reply on trailing semicolon thread [recorded in http://www.w3.org/2011/12/08-svg-minutes.html#action02]

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

jltf draft review request

<heycam> 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 wrong

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 http://www.w3.org/2011/12/08-svg-minutes.html#action03]

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

function based input for animation

<heycam> 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: 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 animations

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

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

<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

<heycam> 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 attributes

<scribe> ACTION: erik to reply to david about function-based animation [recorded in http://www.w3.org/2011/12/08-svg-minutes.html#action04]

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

ChrisL: no

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

mesh gradients

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

<cyril> 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 discontinuity

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

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

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 sharp

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 account?

<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 http://www.w3.org/2011/12/08-svg-minutes.html#action05]

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

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

<scribe> meeting: SVG WG telcon

- DRAFT -

SVG Working Group Teleconference

08 Dec 2011

Attendees

Contents