- From: Rik Cabanier <cabanier@adobe.com>
- Date: Thu, 22 Dec 2011 16:16:16 -0800
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
All, In today's meeting, there was a discussion on how SVG's coons patchs differ from Illustrator's. The examples in http://tavmjong.free.fr/SVG/MESH/Mesh_Boundaries.html showed axial and radial gradients. However, Illustrator doesn't use coons patches for those. It uses type 2 and 3 gradients that are not using patch based. I don't think you should see tensor-product or coons patch meshes as something that can emulate other gradients. It seems that was the conclusion in today's teleconference... wrt to stroking, Illustrator doesn't let you stroke a mesh either because of issue where the mesh can fold over itself. wrt to Illustrator always emitting a clip path, this is actually a remnant of old behavior. When meshes first came out, printers did not have support for them so they had to be emulated with images. There were also bugs in early postscript 3 printers where the bounds were not honored and you got bad drawing . To speed up processing for older printers and work around the device bugs, Illustrator provided a clip path. Rik > -----Original Message----- > From: Erik Dahlstrom [mailto:ed@opera.com] > Sent: Thursday, December 22, 2011 1:36 PM > To: public-svg-wg@w3.org > Subject: Minutes, 22 December 2011 SVG WG telcon > > Minutes: > > http://www.w3.org/2011/12/22-svg-minutes.html > > > and as text below: > > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > SVG Working Group Teleconference > > 22 Dec 2011 > > [2]Agenda > > [2] > http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0109.html > > See also: [3]IRC log > > [3] http://www.w3.org/2011/12/22-svg-irc > > Attendees > > Present > +61.2.980.5.aaaa, heycam, [IPcaller], +33.9.53.77.aabb, ed, > cyril, Tav > > Regrets > Chair > Cameron > > Scribe > ed > > Contents > > * [4]Topics > 1. [5]mesh gradients > 2. [6]SVG2 requirements > * [7]Summary of Action Items > _________________________________________________________ > > <trackbot> Date: 22 December 2011 > > <cyril> yes, don't tell me I woke up early for nothing :) > > <scribe> scribeNick: ed > > mesh gradients > > <Tav> [8]http://tavmjong.free.fr/SVG/MESH/Mesh_Boundaries.html > > [8] 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> [9]http://en.wikipedia.org/wiki/Mach_banding > > [9] 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> > > [10]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#F > ree_audio.2Fvideo_codec_requirements > > [10] > http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Free_ > audio.2Fvideo_codec_requirements > > <cyril> > [11]http://mpeg.chiariglione.org/meetings/geneva11-1/geneva_press.ht > m > > [11] 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> [12]http://www.webm-ccl.org/ > > [12] 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> > > [13]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#T > ooltip_element > > [13] > http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Toolti > p_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> > [14]http://tavmjong.free.fr/SVG/PROGRESSBAR/SteamEngineProgressBar_S > tandAlone.svg > > [14] > http://tavmjong.free.fr/SVG/PROGRESSBAR/SteamEngineProgressBar_StandAl > one.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> > > [15]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#H > it-testing_on_image_alpha > > [15] > 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 > [16]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> > > [17]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A > nchor_events_.28anchorActivated.2C_anchorTargeted.29 > > [17] > http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Anch > or_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> > > [18]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C > onsider_adding_drag_and_drop_functionality > > [18] > http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consi > der_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> > [19]http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd. > html#dnd > > [19] > 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 > [20]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 > [21]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 > [22]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 > > Summary of Action Items > > [NEW] ACTION: CM to investigate how html5 drag&drop could be used in > svg [recorded in > [23]http://www.w3.org/2011/12/22-svg-minutes.html#action02] > [NEW] ACTION: ED to summarize the discussions about hittesting with > alpha from the FX list [recorded in > [24]http://www.w3.org/2011/12/22-svg-minutes.html#action01] > [NEW] ACTION: heycam to investigate how html5 drag&drop could be > used in svg [recorded in > [25]http://www.w3.org/2011/12/22-svg-minutes.html#action03] > [NEW] ACTION: heycam to investigate what document wide events would > make sense to apply to svg documents too [recorded in > [26]http://www.w3.org/2011/12/22-svg-minutes.html#action04] > > [End of minutes] > _________________________________________________________ > > > Minutes formatted by David Booth's [27]scribe.perl version 1.136 > ([28]CVS log) > $Date: 2011/12/22 21:33:12 $ > _________________________________________________________ > > [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [28] http://dev.w3.org/cvsweb/2002/scribe/ > > Scribe.perl diagnostic output > > [Delete this section before finalizing the minutes.] This is scribe.perl Revision: > 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at > [29]http://dev.w3.org/cvsweb/~checkout~/2002 > /scribe/ > > [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ > > Guessing input format: RRSAgent_Text_Format (score 1.00) > > Found ScribeNick: ed > Inferring Scribes: ed > Default Present: +61.2.980.5.aaaa, heycam, [IPcaller], +33.9.53.77.aabb , ed, > cyril, Tav > Present: +61.2.980.5.aaaa heycam [IPcaller] +33.9.53.77.aabb ed cyril T av > Agenda: [30]http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDe > c/0109.html > Found Date: 22 Dec 2011 > Guessing minutes URL: [31]http://www.w3.org/2011/12/22-svg-minutes.html > People with action items: cm ed heycam > > [30] > http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0109.html > [31] http://www.w3.org/2011/12/22-svg-minutes.html > > End of [32]scribe.perl diagnostic output] > > [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > > > -- > Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C > SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 23 December 2011 00:16:46 UTC