SVG Working Group Teleconference -- 22 Dec 2011

<trackbot> Date: 22 December 2011

<cyril> yes, don't tell me I woke up early for nothing :)

<scribe> scribeNick: ed

mesh gradients

<Tav> http://tavmjong.free.fr/SVG/MESH/Mesh_Boundaries.html

TB: i've been looking at cyril's comments on the problems with mesh gradients
... as can be seen in the examples in the link above, there are discontinuity in the gradient
... scroll down, and you can see the same problem for linear gradients too
... look at where the red line breaks

<cyril> mach banding effect I think

TB: probably the brain is geared towards finding discontinuities

CM: where there's a bend in the line, it looks brigther

<cyril> http://en.wikipedia.org/wiki/Mach_banding

CC: not sure it's this exactly, but it's related

TB: with mesh gradients you have the control points along the sides, that not only control the shape but also the spread
... next figure shows the same discontinuities as for the linear gradients but with mesh gradients
... i've moved the control points in the figure with the purple curve, giving a smoother look
... if you change the controlpoints you change two things at once, both shape and color
... the mesh in this case is still a rectangle

CC: would be nice to show the controlpoints in the example, for understanding it better

TB: will add that
... now in "Understanding Coons Patches"
... shows controlpoints, and what you get
... if you move controlpoints further you get discontinuities
... you can never have a derivative of 0 at the edge of a patch

CC: what if you put the controlpoint in horizontal?

TB: can't do that
... they're in colorspace
... 1/3 of the way up and 1/3 of the way down
... it's not a controlpoint for the mesh, it's for the color

CM: are you illustrating the rate of the change?

TB: something like that yes

CM: so the color moves quicker at the start of the curve

TB: i've plotted what happens when you move the controlpoints

CC: are you using the same controlpoints for the upper and lower parts of the curve

TB: yes

CC: you use linear interpolation since you have two colors, you'd have bilinear if you had one color in each corner

TB: just illustrating that it's possible to reduce the effect
... once you move the controlpoint outside the mesh it overlaps itself
... if you introduce a tensor
... you could change the the way the colors inside the mesh are distributed
... doesn't affect the edges
... i've looked at the cairo code and it exploits this to compute the gradient, divides the patch from top to bottom using the tensor points so that you have a series of bezier curves taht are no wider than a pixel
... and then it draws each bezier curve in turn

CC: illustrator doesn't use coons patches
... probably tensor product patches with tensor derivatives
... with bicubic interpolation

TB: what they show in illustration...
... is shown as one patch but is actually many patches
... the boundaries don't correspond to the object, but to the edges to the mesh
... some examples have rough shapes that can't be described by a simple bezier

CM: clipping is another trick

TB: when we discussed it previously there was a request to use the mesh as a clip or by itself

CC: but then tehre would be a problem with the stroke
... not sure if we decided to do it as a paintserver or not

TB: anyway, that's the state atm

CM: does messing with the controlpoints help for eliminating the disconts?

TB: a bit
... by adding extra patches it's possible to smooth it out

CC: i've experimented with corel draw, looks like they do something very similar to illustrator

CM: could the subdivision of patches be useful to define in the document?
... could we describe this simply, and would we want to enable that by an attribute for example?

CC: i think they're approximating, not sure there's a single way to do this
... depends on quality etc

TB: leaning towards letting the author handle it
... if you have a regular gradient you owuld not use meshes, or they would subdivide
... i'm going to read the paper cyril linked to again

CC: let's discuss this at the F2F
... coons patches are fine and you can do good things with them, but there are limitations, and authoring tools solve them atm, but we may want to introduce something like that in the future

TB: we might want to smooth out linear gradients too
... using catmull-rom curves

SVG2 requirements

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Free_audio.2Fvideo_codec_requirements

<cyril> http://mpeg.chiariglione.org/meetings/geneva11-1/geneva_press.htm

CC: this is from MPEG
... one track for MPEG1, since patents are phasing out
... other option is AVC standard but with a baseline where patent holders agree to make it free
... that's not yet decided
... there are big interests, political and economical

CM: what's your sense of these two possible ways forward?

CC: first option is clear in terms of patent conflicts
... if there were other patents they would have been claimed before
... thing is it won't be good quality
... building on mpeg1 is unclear, due to patents
... other option H264 / AVC one, it would be compatible with most exisitng codecs
... but it's a big question for the stakeholders

TB: what does google support in their browser?

CC: on pc it's different from on android
... think they're talking about dropping 264 on pc, and android

TB: what's the fallback?

CC: webm
... but the licensing isn't clear either
... mpeg issued a call for patents covering webm, and got responses (3 digits)

CM: the responses will be published yes?

CC: i think so, next year maybe

CM: in terms of requirements i don't think we should be reuqiring codecs at this point

<cyril> http://www.webm-ccl.org/

CM: it's something that should be done for the whole web platform

CC: apple and microsoft are missing from the webm licensing members list

<cyril> SVG WG supports the goal, including for the whole web platform, but it does not seem feasible at the moment

RESOLUTION: SVG WG supports the goal, including for the whole web platform, but it does not seem feasible at the moment

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Tooltip_element

CM: next tooltip elements
... this has come up before
... i've never really been satisfied with the tooltips in tiny so far
... not clear to me what's a good solution
... he wants a way to generate tooltips

TB: doesn't browsers differ today with what's displayed as a tooltip, <title> or xlink:title

CM: yes I think you're right TB
... html is a bit different because it has a title attribute
... i think our title element has a broader meaning than @title in html
... people are used to what it does in html
... i think we should look into the issue for svg2
... agree with DOH that using metadata with role isn't the right way to do this

CC: maybe a should req?

<Tav> http://tavmjong.free.fr/SVG/PROGRESSBAR/SteamEngineProgressBar_StandAlone.svg

<heycam> SVG 1.1 also says "Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. This is readily achieved by using a different (perhaps user) style sheet."

CM: the document has both <title> and <desc> duplicating the content

ED: don't think any of the browser display <desc> as a tooltip

CM: think we can improve on the requirements for tooltips, to align with html implementation
... so that they're shown under the same circumstances
... we can investigate more when we look into the issue

RESOLUTION: SVG2 will have stronger requirements for when to display tooltips

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hit-testing_on_image_alpha

CM: this was discussed in an FXTF meeting IIRC
... perhaps more generic, with images and fill

ED: probably the proposal from zynga, with masks for mouse events

CC: we could discuss this with alex at the F2F

<scribe> ACTION: ED to summarize the discussions about hittesting with alpha from the FX list [recorded in http://www.w3.org/2011/12/22-svg-minutes.html#action01]

<trackbot> Created ACTION-3190 - Summarize the discussions about hittesting with alpha from the FX list [on Erik Dahlström - due 2011-12-29].

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Anchor_events_.28anchorActivated.2C_anchorTargeted.29

CM: doug is requesting an event for when the link changes
... html already has the hashchanged events

CC: this should be part of the harmonization with html, right?

CM: not sure if we said before if we decided on document level events and such
... think we should consider all the documentwide events
... in html, and make them apply to svg
... where it makes sense

<cyril> "SVG 2 will have HTML document wide events (including hashchange) apply to SVG documents when they make sense"

RESOLUTION: SVG 2 will consider adding HTML document wide events (including hashchange) in SVG documents where they make sense

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_drag_and_drop_functionality

CM: DND in html5 is dragsources and dragtargets, and getting things from other applications
... not with moving elements around
... we should try to get the html5 dnd functionality
... not sure about the dnd for moving things in the document
... probably better to focus on improving the DOM apis for getting the mouse cursor in the variious cooridnate systems, to ease moving things around that way

ED: aligning with html5 on this sounds good to me

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd

ED: and improving the DOM apis too

<scribe> ACTION: CM to investigate how html5 drag&drop could be used in svg [recorded in http://www.w3.org/2011/12/22-svg-minutes.html#action02]

<trackbot> Sorry, amibiguous username (more than one match) - CM

<trackbot> Try using a different identifier, such as family name or username (eg. charles, cmccorma)

<scribe> ACTION: heycam to investigate how html5 drag&drop could be used in svg [recorded in http://www.w3.org/2011/12/22-svg-minutes.html#action03]

<trackbot> Created ACTION-3191 - Investigate how html5 drag&drop could be used in svg [on Cameron McCormack - due 2011-12-29].

<scribe> ACTION: heycam to investigate what document wide events would make sense to apply to svg documents too [recorded in http://www.w3.org/2011/12/22-svg-minutes.html#action04]

<trackbot> Created ACTION-3192 - Investigate what document wide events would make sense to apply to svg documents too [on Cameron McCormack - due 2011-12-29].

RESOLUTION: SVG2 may require drag&drop functionality, and we'll investigate html5's functionality for that

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

22 Dec 2011

Attendees

Contents

mesh gradients

SVG2 requirements

Summary of Action Items

Scribe.perl diagnostic output