SVG Working Group Teleconference -- 29 Jul 2011

<trackbot> Date: 29 July 2011

<ChrisL> Meeting: SVG f2f Seattle

<TabAtkins_> ScribeNick: TabAtkins_

SVG Color

ChrisL: Some links to start.

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Color#Tagged_images

ChrisL: That's a link to a list of stuff I need to get done and want to discuss.

<ChrisL> http://dev.w3.org/SVG/modules/color/master/SVGColor.html

ChrisL: That's the actual spec.

<ChrisL> http://dev.w3.org/cvsweb/~checkout~/SVG/modules/color/master/color-notes.txt?rev=1.2;content-type=text%2Fplain

ChrisL: This is the rougher notes on impls and other stuff that we'll get to if necessary.
... On the first link, I've had a bit of review on the spec recently from interested and knowledgeable people.
... I'm in the middle of editorial revisions to take into account their feedback.
... Also I have an offer of review from the chair of ICC.
... But I want to get the spec into proper shape first so they can focus on important issues.
... Hence this list of editor's issues.

heycam: Are any of these open issues where we need to decide on something?

ChrisL: Some are.
... Let's start with tagged images.
... It's possible to have an image that says it's in a profile but doesn't embed the profile.
... Mostly they do embed their profile.
... The spec says "you must apply the profile if it's available", defined as present, not malformed, etc.
... If it's not present, that counts as not available, so that's okay.

heycam: What's the fallback?

ChrisL: Treat as sRGB.
... We used to have something about overriding the profile.
... Which was a weird thing to want to do.
... Most people questioned the utility.
... So, I've removed that.

heycam: In no-profile situations, is that a use-case?

ChrisL: Yeah, but we specifically say to treat as sRGB there.
... Having looked, there's rarely an issue with mistagged images.
... Authors or authoring tools almost always get it right.
... The problem was that the spec took too much time talking about overriding the profile, and not enough about applying the profile that exists.
... So I've beefed that up with some conformance requirements.
... There used to be a 1.1 test for that, but since it wasn't testable we eventually removed it.
... So I'll move it into the testsuite for this spec, since it is clearly defined.
... The last thing on tagged images is about fallback images.
... We do fallback for colors, but not really for images.
... So maybe something like <switch>, but for some image attribute.
... So if you don't do color matching, use this image; if you do, use this better image.
... So what do we want to do here?
... It's like a feature-string for this module.

heycam: I think that's reasonably simple to do.

vhardy: If you don't do color management, when would you design your content to switch to a different image?

ChrisL: If you do everything in sRGB, and you have a photo, you can convert that photo to sRGB, and it'll match.
... But you'll lose out-of-gamut colors, which the cameras can capture.
... It's easy to save the image as both high-quality and low-quality.

vhardy: And that's better than just ignoring the color profile and interpreting as sRGB?

ChrisL: No, you actually get different RGB values depending on your gamut. If you did that, all the colors would be wrong.

vhardy: So you actually end up with a lower-quality image if you just reinterpret the wide-gamut image.

ChrisL: That's right.
... So should I just make up a feature-string?

shepazu: I have a suggestion, one moment...

<shepazu> for feature strings, I propose the syntax "languageName.elementName.attributeNameOrPropertyName. attributeNameOrPropertyvalue" e.g. "svg.textPath.method.stretch"

<ChrisL> so that is a very different sysntax to the 1.1 feaure strings

<ChrisL> http://www.w3.org/TR/SVG/feature.html

<shepazu> could be http://www.w3.org/TR/SVG11/feature#textPath.method.stretch

TabAtkins_: CSS is also essentially defining feature strings via @supports, and we've decided to be as specific as possible; you must provide a full property/value pair, not just a property.

<ChrisL> if the future syntax id feature strings is undecided, i can just mark it as an issue and fill it in once we have a system in place

<shepazu> http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection

<heycam> ScribeNick: heycam

DS: we need something consistent
... so that's for attributes and properties
... for APIs we could say some other similar syntax

ED: you can always test if the properties exist

DS: I think we should come up with a consistent feature string convention

<scribe> ScribeNick: TabAtkins_

<heycam> ScribeNick: heycam

CL: the next things is the section on definig colours

<TabAtkins_> ScribeNick: TabAtkins_

<heycam> ... this is a complete replacement fro the section in 1.1

<heycam> ScribeNick: heycam

CL: I define all the stuff, so there's a consistent grammar
... in the sRGB section there is a part I no longer agree with
... it says "sRGB" is predefined, and if you point a specific sRGB profile it's ignored
... but there is a need for that
... since there are differences between ICC versions of sRGB profiles
... so I'm going to remove that section
... there's also a need to specify what the transfer curve is for sRGB values that are outside teh gamut
... because the syntax allows that, negative values and values > 100%
... but we don't say what the gamma curve is beyond those points
... so I'm going to propose something there, that the curve is reflexive about the origin and follows a tangent at the end point
... I noticed the way the industry seems to be going is that if people want to use wide gamut sRGB they go with a linear transfer curve
... that's sxRGB
... so I wonder whether we should add that
... the question about what to display with the wrong colour profile, I think that's why this exists
... if you use a wide space and interpret it witj sRGB you get a desaturated image
... but if you use sxRGB, then devices that don't understand it will treat it as sRGB and just clip
... the movie industry, bluray seems to be going for that sort of system
... at this point I think I'll just add an issue for review, saying wondering whether we should add it, and get advice on it

RC: when you talk about the transfer curve, what do you mean?

CL: it's the graph between the inptu and output
... sRGB has a particular transfer curve
... it's like a gamma 2.2 function, but a bit more complicated around the origin
... it's a graph of input values to light level output

RC: from RGB to device independent colour?

CL: no, from RGB to light levels you would measure with a probe

RC: so it's like a combination of two different profiles?

CL: no, it's the final stage when you're generating light at the end of the day
... the maximum level is white, the minimum is black
... the mid value isn't going to be 127

RC: do you as SVG need to worry about a transfer curve? isn't that handled by the monitor and graphics card?

CL: it does handle that...

RC: and you cannot give more than 100% to the graphcis card

CL: you know the CIE horse shoe diagram?
... and the triangle defines the primaries
... so now extend those lines of the triangle out, so instead of meeting at the points they cross and continue on
... you can now make colours outside the triangle, as long as you can use values < 0 or > 100%
... you can now specify the colours anywhere on the gamut
... if that's the physical device, and that's the last device in your chain, you can't go outside
... but if oyu're using it as an input, which might be composited, then you can specify values outside that
... and then would be converted to the rendering colour space

RC: but as soon as you go outside the gamut of the profile, things don't make sense any more?
... how could you ever measure and construct a profile for taht?

CL: you can measure it easily

RC: the profile just describes what the device is capable of displaying

[more discussion of out of gamut colours]

<TabAtkins_> ScribeNick: TabAtkins_

ChrisL: Next is uncontentious.
... CSS3 Color adds hsl, hsla, rgba.
... In CIELAB you need to specify the whitepoint.

TabAtkins_: How does SVG handle transparent colors?

ChrisL: The opacity property combines with the color's own opacity.

TabAtkins_: What about transitions between colors, like in linearGradient?

ChrisL: That should be handle by color-interpolation, likely expanded in the manner you suggested.

heycam: SVG2 is going to reference CSS3 Color, I thought?

ChrisL: SVG Color will also reference CSS3 Color.
... next is rendering-intent.
... If you have a range of colors in an image, and you're trying to map that to a smaller or different gamut, then all the colors which are in the intersection of the gamuts are fine.
... But the outside colors need to be manipulated somehow. How you do this depends on what you want to do with the result.
... In the ICC model, there are four different rendering intents.
... There's absolute-colorimetric (same color if possible), relative-colorimetric (same, but scale the whitepoint), saturation (keep saturation steady, even if hue changes), and finally perceptual.
... If you just clamp colors outside the gamut, gradient's'll look weird, etc, so perceptual scales the whole gamut down so you keep the overall look.
... In SVG 1.1, you can specify a color using ICC.
... You get an sRGB back, but still.
... This guy is working on desktop publishing which goes back to color-managed printing.
... So he's interested in what happens to rendering intent.
... in SVG the only compositing space is sRGB.
... So you convert your CMYK to sRGB, composite, then go back to CMYK for the printer, and you've lost your rendering intent.
... So right now it's an open issue how to preserve that.
... It's unclear in 1.1 whether colors which have opacity are treated differently than solid colors.
... So you can (a) imagine that everything is composited (even if a solid color)
... or (b) only composite if you need to, so opaque colors will be preserved exactly with their rendering intent.
... That has implications with anti-aliasing, etc.
... There may be need for different rendering intents on different elements (photos want perceptual, solid colors want relative-colorimetric).
... So I'm going to put an idea in. Impls would get more complex because they'd need to hang onto the original color and rendering intent.

cabanier: If PDF and PS, you tag the element with the rendering intent.

<cabanier> cabanier: in pdf and postscript, the document, the printer and the device can all specify the default rendering intent

ChrisL: Next is black-point compensation. We don't have a way to specify that right now; I'm wondering if we should have it.
... So imaging you have two color-spaces, and they're mapped to a 3d diagram (black on bottom, white on top)

<cabanier> in addition to that, elements can override the default rendering to get results that are applicable to that content

ChrisL: Imagine a vector from black to white.
... So in one colorspace, the white is a little duller, a little to the side, and you can map between these because you've specified the whitepoint.
... Similarly for black-points, with different color-spaces having different "deepest black".
... It's not clear to me how to specify it.
... But people have asked for it.

vhardy: Are there precedents we can look at?

ChrisL: When ICC updated sRGB to version 4, they produced two profiles, one with and one without blackpoint compensation.
... And in Photoshop, the dialog box has a checkbox for blackpoint compensation when converting between colorspaces.
... So if it's purely something for the output stage, it should be defined in the device profile (which SVG doesn't specify).
... If that's the only place you need, SVG doesn't need to say anything.
... But if you need to do it on input, so you can compensate blackpoint for an image but not the surrounding color, then we'll need something for that.

vhardy: A use-case for input is you taking a picture and knowing that the blackpoint is different?

ChrisL: If the blackpoint for the output device is higher (less dark), then there will be a range of dark colors in the input which will clamp to the single output black.

cabanier: PDF defines it on the input.

ChrisL: So I suggest marking an issue and waiting for feedback.

cabanier: Whitepoint and blackpoint mapping are used on calibrateRGB colorspace.

ChrisL: last issue is preserving black.
... For example, in ICC if you specify cmyk(0,0,0,1), color-management systems tend to have a switch that specially treats that value.
... So even if the system does color-manipulation normally, that one color will instead stay solid, total black.
... This is so black text stays pure black and doesn't mix in other colors.
... So, similarly, we need to see if we need it, and see if it's an input or output feature.

cabanier: We have it in InDesign, and it's an output feature there.
... So we have some special cases there again; you don't want to preserve black on an image.

ChrisL: So that's basically actually being an input feature.

heycam: Does it make sense to have this controllable on images, or if we can magically just apply it to solid-color fills and strokes?
... Also, if you have some colored shapes which are composited together, and you happen to get black out of that, should that be preservable?

TabAtkins_: So it sounds like we can just specify that solid-color strokes and fills automatically preserve black, and nothing else does. It can be applied on output, and doesn't need to be specified on input.

cabanier: So we look at the operator on printing - if a shape is filled with an image or gradient, we don't preserve black. If it's filled with a color, we preserve.

TabAtkins_: So if you composite a partially-transparent gradient over a black rectangle, you wouldn't preserve the black in it.

heycam: So basically, for any image, track if the result color comes partially from a gradient or image. If so, don't preserve black; otherwise, preserve it.

TabAtkins_: So it sounds like we can do this automatically at the end, and thus don't need a property for it.

heycam: And in PDF, it's not controllable; it just happens automatically.

ChrisL: That's it for Color. I'll do another round of edits, then announce it for review and feedback.

heycam: Is the plan to resolve all these issues and then publish, or did you want to publish before that.

ChrisL: We'll need a TR publication with some of these notes and issues in place, for feedback, but it won't be acceptable for LC.
... So after we get feedback, we can clean it up.

shepazu: So is the plan that we make this an SVG feature, and if people ask for it to be in CSS we can merge it in then?

ChrisL: There was some color management in CSS earlier, but there wasn't impl interest so it was removed.
... This is mainly requested by people who want to use SVG and then go straight to print.
... So we'll see print industries implement it first, and then it'll gradually bleed over.
... So right now it's good to have it defined just here in SVG.
... I think it'll be an optional module for SVG2 right now.
... Actually, one more issue to discuss.
... How are we doing tests for SVG2?
... I would like to start putting together some tests for these features.
... Are we doing reftests, or what?

ed: Unless you can test things with script, I'd go with reftests.

<vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements (see test section)

ChrisL: Some of them I can script test, so that's fine.
... Are we using plinss's test harness?

shepazu: That's the plan.

vhardy: I have an action for that. We should have a space for SVG tests right now, and we'll do more when we formalize the framework.

heycam: It should be a simple matter to convert formats when we need to.

vhardy: Couple of questions.
... Re tagged images, you said overriding profiles didn't make much sense.
... What's the history of this feature?

ChrisL: i think it was there from very early on. It was in SVG Print.
... I think at that point color management on the web and on OSes wasn't as good, and there was a concern that people would put the wrong profiles on things.
... But it turns out that's not the case now; if people don't color-manage, they just don't add a profile; if they are, the software tags properly.
... So it's just not a problem today.

vhardy: So it's not a question of someone needing a feature who happens to not be around now?

ChrisL: No.

vhardy: Ok. Is it okay that we didn't actively capture resolutions today?

ChrisL: Yes. I have notes, and I'll bring questions back to the ML.

SVG Vector Effects

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

ChrisL: I have two questions.
... The first feature on the page started in vector effects, and I request that we move it out into SVG proper.
... Currently we have currentColor, which takes the current animated value of the color property.
... So this is well-defined tree-structure inheritance.
... So I can say fill:currentColor or whatever.

<shepazu> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html

ChrisL: So I propose taking this as the basis and expanding it to six values.

<shepazu> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html

ChrisL: currentColor, currentFillPaint, and currentStrokePaint.
... This lets you do the common thing of "how do I do markers that are the same color as the line they're on".
... And then three more which are identical, but rather than coming from the point in the tree, they come from use.
... So you can use this in a <symbol>, and it'll pick up different values from each place it's used.
... Right now we have some magic handwaving that makes it work for <symbol>, but this would remove the handwaving and let you use it elsewhere.

heycam: If we can use this to remove the magical inheritance, we should try to kill the magic handwaving.

ChrisL: Yes, I think we can do this.

heycam: And I think this is more obvious.

<heycam> ScribeNick: heycam

CL: there are two sets of values
... one is "on define" and the other is "on use"

CM: ok

CL: I think these are reasonable
... I want to propose this, can we accept it?

CC: no objection, just a comment
... the currentColor is already something that is not that simple to implement when you consider inheritance, animations
... so adding new values means adding complexity
... I understand the use cases, just pointing out that it's complex

CL: I understand that
... CSS uses inheritance all over the place, so that ship has already sailed
... this is going to be much simpler than the magical inheritance into use

<TabAtkin1_> ed: I think this solves most use-cases; there may be more things you want to inherit than just fills and paints, but this is a good start.

RESOLUTION: We will add new paint values currentFillPaint, currentStrokePaint etc. to SVG 2

<scribe> ScribeNick: TabAtkin1_

<scribe> ACTION: ChrisL to write up spec text for currentFillPaint, etc. [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action01]

<trackbot> Created ACTION-3094 - Write up spec text for currentFillPaint, etc. [on Chris Lilley - due 2011-08-05].

vhardy: Since we have a req document for SVG2, perhaps we can annotate for things with resolutions as hard requirements.

ed: Sounds like going through the last few f2f and tracker.

<scribe> ACTION: ed to go through the last few f2f minutes to find resolutions for SVG2 items, and add them to the wiki page. [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action02]

<trackbot> Created ACTION-3095 - Go through the last few f2f minutes to find resolutions for SVG2 items, and add them to the wiki page. [on Erik Dahlström - due 2011-08-05].

ChrisL: Second things is about constructive geometry.
... Basicall union and intersection to produce new shapes.
... Widely used in 3d.
... It's being criticized as being computationally intensive, and as being possible non-interoperable as getting slightly different results between impls.
... Same rendering, but different underlying nodes.
... These are valid concerns.
... Though, looking at the sbasis library, it does this.

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

ChrisL: And it apparently isn't particularly computationally intensive.
... So, while accepting that we do have some problems, really the whole of VE gets its value from these things.
... You can still do some other useful things, but really the main expressive power is being able to union/intersect geometry here.
... So we either need to resolve these problems, or else just split up VE into bunches of little features. It's like doing Filter Effects without compositing.
... So I'd like to resolve one way or another on whether we're going to pursue it.

vhardy: Can you elaborate on the criticisms?

ChrisL: I think Alex Danilo said it was heavily unspecified.
... There's also concern that if you take the resulting path and know where the nodes are, could you produce another path and animate between them?

heycam: The fact that it doesn't guarantee particular paths... we already have that with normalized path seglist.

ChrisL: Yeah. At the end of the day you get a path that'll render the same in different impls, but if you drill down and try to get a particular control point, you'll get different results.
... Unless we put some pretty rigid constraints on the algorithms.

vhardy: I think that it's a very useful feature. It's in Illustrator, and is used all the time.
... For the platform it's a useful capability.
... So I think our process is to go ahead and spec, and deal with impl feedback as it comes in.

heycam: One of Chris's questions was "will this be easy to specify?
... So I guess we just need someone to try.

cabanier: Is this a scripting API or declarative?

heycam: Declarative, though there may be APIs layered on top later.

ChrisL: Yeah, like asking for a copy of the path so you can use it later.

heycam: And eventually being able to get a path and call .union(otherpath) would be useful later.

ChrisL: So I'm hearing that it sounds useful, we should proceed and see if we run into problems.

heycam: I was one of those that had concerns.
... obviously authoring tools can do it performantly (because they do it)

ChrisL: Yeah, and now we know how some of them do it (convert everything to sbasis curves and do magic).

cyril_: So the intersection always decomposes into a normal path. Is there any real benefit over doing this totally in authoring tools?
... Beyond just basic geom semantics.

ChrisL: I think the main benefit is that if you keep the individual parts, they stay live, so if you change one of the underlying paths the VE is reintepreted.

cyril_: What about filesize benefits?

cabanier: Sometimes smaller.

shepazu: The big benefit is doing this in the browser. Moving things out of the authoring environment into the browser is a good thing.
... I think another thing we don't do in VE right now is, it doesn't have an API.

<ChrisL> It would be interesting to investigate that. I think the result of stroke to path is going to be larger than the original path plus the vector effect elements

shepazu: So anything available through the element-based syntax should also be doable via API.
... Then we can also do this in Canvas, frex.

heycam: I think the arguments for doing VE are similar to the arguments for doing text warping, etc.

RESOLUTION: Keep constructive geometry operations in VE and see if it's possible.

heycam: I think it's still possible that in the end we discover that it's too complex, but we totally want to try and do it first.

shepazu: So is this part of SVG2, or is it part of a module?

<ChrisL> currently its edited as a module

heycam: I think keep it as a module for now. It gives it better visibility.

<ChrisL> it can always be merged later

<tbah> OK, I'll call in anyway. The girls are in bed. Peace has returned.

<vhardy> ScribeNick: vhardy

SVG Compositing

Advanced Gradients

<tbah> http://tavmjong.free.fr/SVG/MESH/Mesh_Inkscape.html

tav: I have taken what was proposed as a structure for mesh-gradients and patched InkScape to use that
... I added this in my private copy of InkScape.

tab: I have also Coons patch mesh gradients in Canvas

tav: So you have a way to defining them?

tab: yes, and an implementation.

<TabAtkin1_> Apropos of text stroking,

tab: it is a JS impl

<TabAtkin1_> http://www.xanthir.com/etc/text-stroke-start.html

heycam: I came up with a syntax and then got feedback from tab

tav: I have produced some interseting gradients.
... cairo has bugs with that type of gradients.
... I get crashes in some casess.
... you can see the definition of the gradients in the code sample.
... there is a <meshGradient>, a <meshRow> and a <meshPatch>
... then there is a sphere with four patches
... then there is conical gradients that can be done with meshes as well.

<scribe> ... done with one zero-length size.

UNKNOWN_SPEAKER: then a 6x6 patch mesh gradient.
... the performance is good enough.

<tbah> http://tavmjong.free.fr/SVG/MESH/Mesh.html

UNKNOWN_SPEAKER: the gray box half way down is the syntax proposed.
... the way it is defined is an array of patches aligned in rows.

<ChrisL> like a table

UNKNOWN_SPEAKER: ther eis a <meshRow> which defines the begining and then a <meshPatch> with has four stops. The stops have a stop-path.
... you could have a curve or a line. Cairo supports curveto and lineto
... you need a Bezier curve. If you need other curves, you need to translate to Bezier.

shepazu: this seems pretty verbose.
... I am not sure how to make it more concise.

tav: you could combine the paths into one and then you could specify the colors for the corners.
... I think I like this better.
... it is always a quad.
... if the last two points coincide, you could skip them.
... the moveto is needed to start the path. That is the x/y of the meshGradient. Then you have the additional the curves. For the last one, you do not need the last point because it is a closed path.

cabanier: can you have disjoined patches?

tav: no.
... if you want to be able to edit that, then you start with a single patch and then start dividing.
... the second patch is attached to the right of the first patch.
... you can distort the array any way you want, like in the conical gradient example.
... conceptually, you need an array, top, left right.
... Moving on to  in the gray section.
... note that the first path is ommited because it is taken from the bottom patch of the patch above.
... next patch, you only need to specify 2 of the paths, because the top and left path are coming from the previously specified colors.

heycam: if you specify a color which you already know?

tav: it is ignored.
... then I list changes from what Tab had proposed.

heycam: I am not sure stop-path is the best name. Attributes with a dash are properties, e..g, stop-color is a property.
... it should probably be path.

vhardy: or 'd'

RESOLUTION: rename stop-path to 'd' or 'path'

shepazu: since it is not exactly the same syntax as 'd', it probably better to use 'path'
... I wonder if we are going to have Catmull Rom curves, it might be useful to have that.

tab: we should allow any given path segment that <path> has.

<ChrisL> yeah but if libraries are constraind to bezier paths then that is what you would need to use

cyril: how do you use stop-opacity?

tav: yes, you can. I have not done an example, but the Cairo code allows it.

cyril: do you have spread and pad methods.
... I think it is not a good idea.
... how would you use it?

tab: it feels more like a geometric primitive, and not a fill?

tav: in the last example I did, it fills the rectangle completely.
... the edges are outside the rectangle.

cyril: what is the coordinate system for the mesh?

tav: same as other gradients.

<ChrisL> gradientUnits="userSpaceOnUse"

cyril: so what about padding and reflection?

tav: how do you reflect somethign that is not a straight line?

tab: there is no notion of padding and reflecting.

cabanier: how would you do that?

tab: there is a possibility to extend the gradient outside the edges of the patch, by reflecting the mesh.

tav: what I have shown are symetrical gradients. People will use it to shade car seats, facial features. I am nto sure it is useful to pad and reflect.

cyril: don't you want the geometry of the shape to match the mesh's geometry?

tab: yes, the mesh would match the geometry.

cyril: if you are going to use these gradients with a rectangle, fine, but if you use them with a path, shouldn't we use the path geometry for the mesh's defintion.

tab: I thought of that initially.
... the last example (the lamp head), looks like it should be a geometry.

tav: the lamp is one mesh gradient defined with many small patches. Four rows of patches.
... this shows how an authoring tool would work.
... the mesh structure is important to be able to edit the mesh easily in a tool.
... Illustrator only does arrays for meshes as well.

cabanier: using an array of patches is the most common use case by far. PDF has more capabilities, but they are less commonly used.
... we have techniques to compress the mesh data.
... is this needed in SVG?

tab: yes, it is commonly used in authoring tools.
... should it be a geometric primitive?
... I could see the path warping used for other things (warping shapes, text, images, four color interpolation).
... the mesh could be a geometric primitive and then take a fill of its own.

heycam: we cannot do the square patch gradient right now.

tab: we would need to define a new gradient for that.

heycam: I am not sure. Some are very object specific, some are not.
... e.g., a rainbow.

tab: yes, I can see that. But very often, you want to have the mesh and the object geometry match.

heycam: what about having a patch reference the outside edge of a path.

cabanier: that does not always work, like in the mesh wild example.

heycam: yes, that would not work.

shepazu: we ran into this with other case.

heycam: there seem to be different use cases, one where it is generic and reusable and one where the mesh matches the object.
... neither way seems exactly right.
... what about PDF?

cabanier: for meshes, there is a fill operator that does not rely on having a path.
... so the mesh is an object and you cannot stroke it.
... there is a second way where it is like a paint server.
... one is a geometric primitive and the second way is a paint server.

tab: It could be done where the paint server renders if not in a <def> but can be referenced like other paint servers.

shepazu: in SVG 1.1, you cannot just use anything as a marker or a clip-path and we went to have elements that defined the marker or the clip-path.
... you need to specify additional information.
... like transform, coordinate space.

<ed> s/<def>/<defs>/

heycam: I like tab's idea.

RESOLUTION: mesh gradients are accepted by the WG for SVG 2.0.

<scribe> ACTION: tbah to update the coon's mesh proposal to make it both a geometric primitive and a paint server. [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action03]

<trackbot> Created ACTION-3096 - Update the coon's mesh proposal to make it both a geometric primitive and a paint server. [on Tavmjong Bah - due 2011-08-05].

<tbah> I just got kicked out.. what was the conference code?

<ChrisL> i got kicked out as well

current gradient issues.

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Gradients

<tbah> zakim +39.537 is me

http://apike.ca/media/svg/exampleRadGradFP.svg

<cyril_> http://perso.telecom-paristech.fr/~concolat/exampleRadGradFP.svg

ed: this behaves differently in all browsers

heycam: when the focal point is within the shape and you have reflect or repeat, you are supposed to reflect the whole gradient to fill the shape, but the spec. does not say how to do that exactly.

cyril: the issue is when the focal point reaches the edge of the gradial gradient

<ChrisL> more is the pity, zakim

<cyril_> s/gradial/radial/

<ed> http://www.w3.org/TR/SVG11/pservers.html#RadialGradients

ed: FF has the most sensible interpretation.

<ChrisL> so I see lack of sub-pixel precision in the opera rendering

ed: if we want interoperable behavior, this needs to be clarified in the spec.

heycam: it seems like the Firefox behavior looks the most reasonable.

ed: may be some people would like something different.

vhardy: is that really a spec. problem?

<ed> "Indicates what happens if the gradient starts or ends inside the bounds of the object(s) being painted by the gradient. Has the same values and meanings as the ‘spreadMethod’ attribute on ‘linearGradient’ element."

<ed> this is for spreadMethod on radialGradient

ed: yes, because the spec. for reflection on radialGradients is not precise enough, it only says to do the same thing as linear.

<ed> this is what it says for spreadMethod on linearGradient:

<ed> "Indicates what happens if the gradient starts or ends inside the bounds of the target rectangle. Possible values are: 'pad', which says to use the terminal colors of the gradient to fill the remainder of the target region, 'reflect', which says to reflect the gradient pattern start-to-end, end-to-start, start-to-end, etc. continuously until the target rectangle is filled, and repeat, which says to repeat the gradient pattern start-to-end, start-to-end, start-to-end, et

<ed> c. continuously until the target region is filled.

<ed> If the attribute is not specified, the effect is as if a value of 'pad' were specified."

(group experimenting with the example)

<ed> "If the point defined by ‘fx’ and ‘fy’ lies outside the circle defined by ‘cx’, ‘cy’ and ‘r’, then the user agent shall set the focal point to the intersection of the line from (‘cx’, ‘cy’) to (‘fx’, ‘fy’) with the circle defined by ‘cx’, ‘cy’ and ‘r’."

Summary of the issue: when the focal point is on the circle edge, with repeat, then the distance between the first and last stop for the repeating colors is 0 and the spec. does not define what should happen.

tab: for the same problem with linear gradients in CSS, we resolved to have the average color of all the gradient stops.

RESOLUTION: the spec. should say that when the focal point is on the circle edge, with repeat, then the distance between the first and last stop for the repeating colors is 0 and the paint should generate a color that is the average of all the gradient stops.

<ed> s/the average/the weighted (by offset) average/

<scribe> ACTION: ed to propose wording for the edge case where a radialGradient's focal point sits on the edge of the circle and the gradient repeats. the spec. should say that when the focal point is on the circle edge, with repeat, then the distance between the first and last stop for the repeating colors is 0 and the paint should generate a color that is the average of all the gradient stops. [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action04]

<trackbot> Created ACTION-3097 - Propose wording for the edge case where a radialGradient's focal point sits on the edge of the circle and the gradient repeats. the spec. should say that when the focal point is on the circle edge, with repeat, then the distance between the first and last stop for the repeating colors is 0 and the paint should generate a color that is the average of all the gradient stops. [on Erik Dahlström - due 2011-08-05].

fr attribute on radialGradients

ed: canvas can define the inner circle that the radial gradient focuses on. SVG could/should align to that by adding an fr attribute to control the focal radius.
... fr would define where you would hav the zero offset for stops.

RESOLUTION: add an fr attribute to <radialGradient> for SVG 2.0.

<scribe> ACTION: ed to provide spec. wording for the fr attribute on <radialGradient> [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action05]

<trackbot> Created ACTION-3098 - Provide spec. wording for the fr attribute on <radialGradient> [on Erik Dahlström - due 2011-08-05].

LUNCH BREAK

<heycam> ScribeNick: jenyu

Compositing

<cyril_> http://www.w3.org/TR/SVGCompositing/

<cabanier> comments from Alex: The main problem I see now (after

<cabanier> all this time not bothering to notice) is that we've mixed two orthogonal

<cabanier> things into the one property.

<cabanier> P-D dictates the combination logic for each of the 4 alpha blend

<cabanier> areas, namely src, dst, src&dst, no src or dst as the diagram at the top

<cabanier> of the compositing spec. shows (the big square with coloured areas - yellow,

<cabanier> mixed, blue and white).

<cabanier> What the blending modes do is apply only to the top triangle which

<cabanier> manages how you mix src & dst. In all the blend modes, we are assuming

<cabanier> P-D src over which is compatible with PDF, etc.

<cabanier> But the problem I see now is that's too restrictive. It may well

<cabanier> be nice to use an 'in' operator to restrict the effect to the intersection

<cabanier> of two objects but have them combined with a blend mode (like overlay, etc.)

<cabanier> That seems an obvious thing to do, but there is no way to do it as the

<cabanier> spec. is written now. We've overloaded 'comp-op' and this isn't possible.

<cabanier> So the only way to achieve that is to use a clip path and clip

<cabanier> one object against the other and use the correct comp-op to get the

<cabanier> color mix correct which is quite a hack.

<cabanier> In hindsight I'm a bit surprised this hasn't been noticed before

<cabanier> but that's most likely due to lack of implementations and scrutiny.

cabanier: question: do we keep the adobe blending modes (aligned with current spec) or porter duff?
... porter duff seems too primitive for SVG

<cyril_> adobe blending modes: http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

: what's the hardware support for the blend modes like?

cabanier: adobe modes can be done in hardware; pixel shaders are always possible anyway

<cyril_> chapter 11, table 136, in http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

heycam: can you do these with filters? there's feComposite and feBlend

<vhardy> http://www.w3.org/TR/SVG/filters.html#feBlendElement

vhardy: we should be consistent in our blend modes in filters and compositing

cabanier: alex proposed that we should remove the underspecified compositing features and spend time carefully specifying the needed features
... you can achieve effects with filters but it makes it hard to read

heycam: given that we are introducing the filter property, does it make sense to make compositing a shorthand to a filter?

vhardy: describing it as a comp-op is a much clearer model than using filters

heycam: what's the difference between blend and general compositing operations?

vhardy: blend modes -- you have a destination and need to composite a shape onto it; porter duff -- take 2 bitmaps and figure out how to combine them

<vhardy> http://www.w3.org/TR/SVGCompositing/#containerElementBackgoundControl

vhardy: blend is a function of destination and source pixels <-- definition of compositing operation. clip-to-self adds a clipping operation to that compositing operation. porter-duff and adobe blend modes just use different formulas for the compositing operations

cyril: is it implicit that compositing operations are chained?

vhardy: the painting algorithm is followed, so yes comp-ops apply in a sequential chain

cabanier/cyril: [drawing nested g elements on the board with comp-op property]

vhardy: [drawing more nested groups and shapes on the board, some with comp-op]
... [top-level group contains enable-background="new" for the comp-op operations in its child elements]

heycam: why do we even have enable-background=accumulate? why don't we just start a new buffer every time there's a compositing operation?

cabanier: this was discussed previously. peter has a use case for it and feels strongly about it

heycam: it will be hard to reach a resolution. not many people understand this completely

cabanier: the pdf file describes this in detail (which is very similar to compositing described in the SVG spec)
... the knock-out property seems ill-defined. the formulas are not quite correct

vhardy: we need 1) a description that the group can easily understand about why to split out porter-duff and blend modes and what the differences are, with examples and 2) is enable-background the same for compositing as it was in SVG1.1?

<scribe> ACTION: Give a description of how porter-duff behaves differently from blend modes (group invariance) [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action06]

<trackbot> Sorry, couldn't find user - Give

<scribe> ACTION: cabanier to Give a description of how porter-duff behaves differently from blend modes (group invariance) [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action07]

<trackbot> Created ACTION-3099 - Give a description of how porter-duff behaves differently from blend modes (group invariance) [on Rik Cabanier - due 2011-08-05].

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/CSSDependencies

css dependencies

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/CSSDependencies

ChrisL: In SVG2, we should depend on CSS2.1. SVG1.1 depended on CSS2. There have been some changes between the two, primarily the box model (doesn't affect SVG) and selector precedence (but practically speaking, this isn't an issue since everyone aligns with CSS2.1 here, including the svg 1.1 tests)

ed: the clip property is another one that changed from CSS2 and 2.1
... browsers aren't interoperable on the clip property so no one uses it anyway

resolution: SVG2 will depend on CSS2.1
... SVG2 will depend on CSS3 Fonts

ChrisL: Virtual text and bidi is implemented in some of the plugins that supported SVG but not in many browsers

heycam: text layout should occur according to writing modes and have text positioning and glyph layouts occur afterwards

resolution: SVG2 will depend on CSS3 writing modes
... SVG2 will use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG
... SVG2 will depend on CSS3 Color

ChrisL: Media queries are useful for conditional formatting such as for printing

heycam: do we want to require support for CSS Animations/Transitions?
... it's too early to depend on it

vhardy: maybe we can depend on the result of the results of the FX task force

resolution: SVG2 will depend on CSS3 Media Queries

schepazu: SVG2 should point to a bunch of different modules -- eg filters can point to the Filters spec, animations can point to CSS animations. The spec itself can be smaller.

heycam: we are not going to depend on CSS Transitions/Animations yet.

shepazu: what's the timeframe for SVG2?

ChrisL: CSS3 Image Values

cyril: CSS3 image values as SVG paint servers, we should include it

sylvaing: CSS3 Image values was split into 2 specs -- CSS3 and CSS4 image values. 3 includes gradient, element,

resolution: SVG2 will depend on CSS3 Image Values and CSS4 Image Values

ChrisL; SVG 1.1 depends on selectors in CSS2, but there's now CSS3 selectors that's about to be published and proposed rec status

ChrisL: We should adopt the selector and namespace spec for SVG2
... CSS style attribute syntax

resolution: SVG2 will depend on CSS style attribute syntax

<ChrisL> http://www.w3.org/Style/CSS/specs#text

<ChrisL> "The Text module has been split into three parts: Text, Writing Modes, and Line Grid."

resolution: SVG2 will depend on CSS3 Selectors and CSS3 Namespaces

<ChrisL> Line Grid describes text where each symbol in a line is aligned to an invisible grid, so that symbols in all lines line up verticall

resolution: SVG2 will depend on WOFF

<ChrisL> draft css charter for next 2 years

<ChrisL> http://www.w3.org/2010/09/CSSWG/charter.html#deliverables

resolution: SVG2 will depend on CSS UI and CSS Values and Units

<heycam> ScribeNick: heycam

Next F2F

CM: I think we agreed to meet both adjacent to SVG Open and at TPAC

<ed> http://www.w3.org/2011/11/TPAC/

CL: I think we agreed to meet for a couple of days before SVG Open
... plus the 2 days at TPAC
... and I think we decided before SVG Open so that we could give status updates at the conference

<cyril> SVG Open 2011: October 17-20

<cyril> TPAC 2011: 31 October to 4 November 2011

CC: some people would want to come just for one of the halves of the WG meeting
... or maybe both meetings but not SVG Open

<ChrisL> http://www.svgopen.org/2011/registration.php?section=conference_schedule

CL: the workshops are on the fourth, the thursday

<ChrisL> s/fourth/fourth day/

<ChrisL> in my calendar we have thurs and fri as the f2f

<ChrisL> http://www.w3.org/2011/11/TPAC/#Finalized

CC: how about moving the two days of additional F2F meeting time to just before TPAC instead of just after SVG Open

CM: that makes sense to me

CL: have the two days on 27th and 28th (Thursday and Friday)?

CM: ok, let's ask MS to host, and if not perhaps Google can

RESOLUTION: We will meet on 27th and 28th October for the first half of our F2F

SVG 2 scope

DS: I can see two ways of approaching the problem
... we can either go at it from a schedule perspective, or a feature perspective
... in the former, just see how much we can get done in a certain time
... alternately, we could say these are the features we want to have, we take as long as it needs

CL: I thought we would go somewhere in between
... decide roughly what features we want, see how it goes, drop some features if they are slowing things down

DS: I would kind of like to have a schedule we can work with

CC: you will have to keep to your schedule
... you were talking about 1, 2 or 3 years?
... I don't think 1 year is possible

CL: I think a year is ridiculous unless we're already in CR
... I also don't want to just produce an SVG 1.1 rewritten in new words but has exactly the same features

CC: if we say to the world we are starting on a new version, people may come forward with new features they want
... and we'd have lots of things to deal with
... I agree 1 year is impossible

JY: if you throw out unrealistic numbers ...

CM: so two years until what?

CC: rec?

VH: in software development you set out a date for when you want to do something that seems on the outskirt reasonable, achievable
... and try to lay out a plan to get there, think about your features
... and then you start executing
... when you get through the milestones you adjust your schedule, or you lighten the boat and still make the date

SG: features, quality, ship date. you can have only two.

VH: I think it's good to have a goal
... if you have a schedule like doug is asking, we can have milestones for what we want to achieve
... maybe by the next F2F we can freeze our requirements document

CM: that's a good concrete suggestion

DS: one reason I'm asking is that we got pushback on our charter since we didn't have any dates in there
... they want milestones in terms of "when are you getting to FPWD, LCWD, etc."
... I think there's another way of gauging milestones
... when are we going to have a test suite, complete implementations, etc.

VH: if you take the regular track process, we additionally need a goal for the requirements document in some form
... and then a goal for the test suite

DS: I'd rather have that worked on continuously while we're doing it

VH: so we may set ourselves our own goals

SG: in CSS we have someone who owns the test suite to check for normative statements, etc.

DS: in one group I'm in, we didn't do it, but we thought hard about saying the criteria for going from Editor's Draft to FPWD is to have tests for it
... which is a pretty heavy discipline, we didn't end up going for it, but we should consider it
... everyone agrees it's a great idea, right?
... what are the incentives and mechanisms we're going to use to decide if a spec section is mature?

ED: I liked how the CSS test harness listed how many tests there were for a given section

DS: if we pair that with markup with the spec itself, that indicates thte normative assertions, and we can say there are 14 testable assertions and 25 tests

VH: I really like what Sylvain was saying. a good way to ensure we make progress is to try to have people focus on different things. for SVG 2.0 we need to do work on tests, we need to do work on new features like RIk on Compositing
... that's clearly work as well
... the other part would be integration of new features in the spec and adapting the spec to the new CSS references
... we need one or two editors that integrate new work, changes to references, and people who provide content for the spec
... so we should authors for sections
... and we should have people assigned to work on tests
... for SVG 1.0 we had nearly all the group work on the test suite
... now we have a whole body of tests...

CM: people who are working on new features are probably the best people to write tests for it, though

DS: when I write tests it helps me with the prose writing

VH: if we follow what Sylvain was saying, should we try to organise our work around these roles?
... we have clear milestones for the spec overall -- a first one is just to get the spec building
... and then we can grow that

DS: I think it would be really good if we could demonstrate rather quickly, some time this year, to have a FPWD
... by mid november say

ED: I agree
... it should include some new features by then too

CC: we already have decided on some new things here, like catmull-rom curves

ED: we should highlight these new things

DS: we could have the catmull-rom curves specced out fairly quickly
... we have a script implementation

VH: how do we capture that? on the wiki?

ED: yeah

VH: I will create a page

ED: I think it's a good idea to have at least two people driving each feature
... so they can review each others' work

VH: we should have a "what's new in SVG 2" section in the spec

CL: I'm a bit worried about overpromising
... but I like the idea of testing up front

ED: I think we should have one person at least driving a feature, and one person assigned to be the reviewer of that section

CC: coming back to timeframe
... it's difficult to say when we want to produce a final REC or PR
... but I think we can say what we don't want to do
... five years is too much
... one year is too little

<ChrisL> 3

CM: having issued First Last Call WD by two years?

<ChrisL> sure

VH: I think we should have feature list settled by TPAC
... like gradient meshes, path improvements, etc. and say that's closed

DS: also we have to worry about how long implementations will take to catch up
... we definitely need new features, but once we have the momentum going we can always add more

CC: do you plan to have a "call for features"?

DS: we talked a bit about that before. we have already sort of made a bit of an open call for features. we'll ask again, when they see we're serious... with a FPWD

VH: let's have a proposed requirements document to bring in to TPAC
... and to resolve on it at that meeting

DS: we should have use cases for them, too

VH: they should be in that document

CC: and examples of existing technologies doing it

VH: I will add some proposed milestone dates to the wiki page and we can discuss that on a telcon soon

DS: one set of use cases and requirements that I'm interested in is looking at WebCGM and seeing what precisely SVG would need to have to replace WebCGM
... we've had a lot of people ask for this

SG: that's a source of use cases there

<cyril> s/existing technlogies/existing technologies (proprietary or not)/

CC: we should look at SVG Tiny 1.2 to see what features there we want to bring forward

<scribe> ACTION: Cyril to look at SVG Tiny 1.2 and come up with a list of major features that aren't in 1.1 [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action08]

<trackbot> Created ACTION-3100 - Look at SVG Tiny 1.2 and come up with a list of major features that aren't in 1.1 [on Cyril Concolato - due 2011-08-05].

http://www.w3.org/Graphics/SVG/WG/wiki/Proposals

VH: somebody should own the requirements document

http://www.w3.org/Graphics/SVG/WG/wiki/Proposals

Media resources spec review

ED: I posted some comments to our list for review

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0025.html

<cyril> http://www.w3.org/TR/mediaont-api-1.0/

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0024.html

<scribe> ACTION: Cyril to respond with comments on the API for Media Resources 1.0 spec [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action09]

<trackbot> Created ACTION-3101 - Respond with comments on the API for Media Resources 1.0 spec [on Cyril Concolato - due 2011-08-06].

sharing path segments

CC: if you look at this wiki page

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements

scribe: the shared/reverse path link is an SVG Open presentation my colleague presented last year
... one use case is maps, the other is comics
... in those kinds of content, you re-use many paths
... sometimes you use them as a border of two regions
... sometimes when you mkae holes in a shape, by overlapping another shape on top of it, you may have shared borders there
... he tried to work on solutions to reuse this path
... if you look at slide 16 he proposed a syntax using superpath and subpath
... he discovered vePath and vePathRef in SVG 1.2 Full
... the gist of it is, we think it's important to have this feature in SVG, the ability to create apath by concatenating existing paths and reversing them
... it's important for animation, file size reduction, doing adaptation like LoD with consistent degredation of paths
... so we think it's important to be in SVG 2
... don't care if it's vePath or superpath

DS: this seems very closely linked to the idea of the extended path syntax where it expands out into elements

CC: the canon proposal?

DS: the one used for EXI
... instead of a compact syntax...

CC: it's a different thing
... compact vs non-compact has dom implications
... I just want to talk about requirements first
... do you agree it would be nice?

DS: yes

CM: yes

CC: then syntax discussion

DS: styling, if they're shared paths -- if the outline of germany is one colour and the outline of france is another, what would be rendered?
... you could have only inner strokes and then the countries edges would not overlap

<scribe> ACTION: Cyril to write up proposal page for path shared edges [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action10]

<trackbot> Created ACTION-3102 - Write up proposal page for path shared edges [on Cyril Concolato - due 2011-08-06].

polar element

DS: there were some discussions, Dr O made a proposal

<shepazu> http://svg-whiz.com/svg/StarMaker.svg

DS: we never ended up having a regular polygon/star shape
... you can do them, but it's not trivial
... it would be good for dynamic updates to have a geometric star shape than a path you have to change the geometry of

<ed> http://hoffmann.bplaced.net/svgueb/polar.php

DS: Olaf's page can do more complex things than mine

CC: why does it need to be declarative? for animations?

DS: you can do it in JS, but sometimes I just want to say "I want a hexagon that fits in this box"

CM: with the path rotation command it becomes reasonably easier to do regular polygons
... stars too

CC: so we agree on the use case
... we have these three ways we can do it, your polar, olaf's polar, path rotation command

DS: spirals is another one

<scribe> ACTION: Doug to make a wiki proposal page for polar/star/polygon/path extensions [recorded in http://www.w3.org/2011/07/29-svg-minutes.html#action11]

<trackbot> Created ACTION-3103 - Make a wiki proposal page for polar/star/polygon/path extensions [on Doug Schepers - due 2011-08-06].

<vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page#Test_Suite_Requirements

vhardy, http://www.w3.org/Graphics/SVG/WG/track/actions/3045

- DRAFT -

SVG Working Group Teleconference

29 Jul 2011

Attendees

Contents

SVG Color

SVG Vector Effects

SVG Compositing

Advanced Gradients

current gradient issues.

fr attribute on radialGradients

Compositing

css dependencies

Next F2F

SVG 2 scope

Media resources spec review

sharing path segments

polar element

Summary of Action Items

Scribe.perl diagnostic output