W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2011

RE: Minutes, 22 December 2011 SVG WG telcon

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>
Message-ID: <8A13F0222395BD428969E5BA529EFA748A44A577FA@NAMBX01.corp.adobe.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 December 2011 05:09:02 GMT