- From: Rik Cabanier <cabanier@adobe.com>
- Date: Thu, 22 Dec 2011 21:08:17 -0800
- To: "'Cyril Concolato'" <Cyril.Concolato@cisra.canon.com.au>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hi Cyril, Yes, it's true that Illustrator creates many patches for a simple 2x2 mesh gradient. I'm unsure why that is but I'll look through the code to find out. Did you verify that a 2x2 patch in Postscript or PDF matches your results? Rik > -----Original Message----- > From: Cyril Concolato [mailto:Cyril.Concolato@cisra.canon.com.au] > Sent: Thursday, December 22, 2011 7:25 PM > To: Rik Cabanier; public-svg-wg@w3.org > Subject: RE: Minutes, 22 December 2011 SVG WG telcon > > Hi Rik, > > The purpose was not to use Coons patches to make linear or radial gradients. > Tav's page is using a linear gradient as an example to illustrate/investigate the > fact that Coons patch (because they use bilinear interpolation) cannot achieve > smooth interpolation across patches. You have to use many patches for that. > See http://www.w3.org/Graphics/SVG/WG/wiki/SVG2GradientsComments. It > seems that it's what Illustrator is doing: showing a smooth gradient (from a > simple mesh) in the Illustrator window but exporting it as a smooth gradient > (made of a complex mesh) in PDF using Coons patches or Tensor product > patches. > > Regards, > Cyril > > -----Original Message----- > From: Rik Cabanier [mailto:cabanier@adobe.com] > Sent: Friday, 23 December 2011 11:16 AM > To: public-svg-wg@w3.org > Subject: RE: Minutes, 22 December 2011 SVG WG telcon > > 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 > > The information contained in this email message and any attachments may be > confidential and may also be the subject to legal professional privilege. If you are > not the intended recipient, any use, interference with, disclosure or copying of > this material is unauthorised and prohibited. If you have received this email in > error, please immediately advise the sender by return email and delete the > information from your system.
Received on Friday, 23 December 2011 05:09:00 UTC