See also: IRC log
<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
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
<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> 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
<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].
<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].
<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> <animatePath xlink:href="#curve1" xattribute="cx" yattribute="cy"/>
<heycam> <animatePath xlink:href="#curve2" xattribute="rx" yattribute="ry"/>
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
<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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/cc:/cyril:/ Succeeded: s/textPath, indexes are from start of path not start of element/textPath or tspan, indexes are from start of that element not the start of the <text> element/ Succeeded: s/do one line/so more than one line/ Succeeded: s/tfo/t fo/ Succeeded: s/the explicit/explicit/ Succeeded: s/to do/to dot/ Succeeded: s/no new dependencies/it introduces no new element-to-element dependencies/ Succeeded: s/attra/attributes/ Found ScribeNick: ChrisL Found ScribeNick: ChrisL Inferring Scribes: ChrisL Default Present: [IPcaller], ed, heycam, Tav, cyril, Doug_Schepers, ChrisL, Vincent_Hardy Present: [IPcaller] ed heycam Tav cyril Doug_Schepers ChrisL Vincent_Hardy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0100.html Found Date: 08 Dec 2011 Guessing minutes URL: http://www.w3.org/2011/12/08-svg-minutes.html People with action items: cameron chris cyril erik respond[End of scribe.perl diagnostic output]