IRC log of svg on 2011-07-29

Timestamps are in UTC.

16:08:48 [RRSAgent]
RRSAgent has joined #svg
16:08:48 [RRSAgent]
logging to
16:08:50 [trackbot]
RRSAgent, make logs public
16:08:50 [Zakim]
Zakim has joined #svg
16:08:52 [trackbot]
Zakim, this will be GA_SVGWG
16:08:52 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
16:08:53 [trackbot]
Meeting: SVG Working Group Teleconference
16:08:53 [trackbot]
Date: 29 July 2011
16:09:06 [ed]
RRSAgent, this meeting spans midnight
16:09:16 [ChrisL]
Meeting: SVG f2f Seattle
16:09:23 [heycam|away]
Zakim, room for 3?
16:09:24 [Zakim]
ok, heycam|away; conference Team_(svg)16:09Z scheduled with code 26631 (CONF1) for 60 minutes until 1709Z
16:09:33 [ChrisL]
rrsagent, this meeting spans midnight
16:09:35 [heycam]
Zakim, code?
16:09:35 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200, heycam
16:09:48 [Zakim]
Team_(svg)16:09Z has now started
16:09:55 [Zakim]
+ +1.206.675.aaaa
16:10:30 [Zakim]
16:11:14 [cyril]
cyril has joined #svg
16:16:00 [jenyu]
jenyu has joined #svg
16:16:30 [TabAtkins_]
ScribeNick: TabAtkins_
16:16:35 [cyril_]
cyril_ has joined #svg
16:16:55 [ChrisL]
Topic: SVG Color
16:17:39 [vhardy]
vhardy has joined #svg
16:17:43 [TabAtkins_]
ChrisL: Some links to start.
16:17:43 [ChrisL]
16:18:03 [TabAtkins_]
ChrisL: That's a link to a list of stuff I need to get done and want to discuss.
16:18:06 [ChrisL]
16:18:13 [TabAtkins_]
ChrisL: That's the actual spec.
16:18:25 [ChrisL];content-type=text%2Fplain
16:18:34 [TabAtkins_]
ChrisL: This is the rougher notes on impls and other stuff that we'll get to if necessary.
16:18:53 [TabAtkins_]
ChrisL: On the first link, I've had a bit of review on the spec recently from interested and knowledgeable people.
16:19:04 [TabAtkins_]
ChrisL: I'm in the middle of editorial revisions to take into account their feedback.
16:19:11 [sylvaing]
sylvaing has joined #svg
16:19:12 [TabAtkins_]
ChrisL: Also I have an offer of review from the chair of ICC.
16:19:24 [TabAtkins_]
ChrisL: But I want to get the spec into proper shape first so they can focus on important issues.
16:19:32 [TabAtkins_]
ChrisL: Hence this list of editor's issues.
16:19:43 [TabAtkins_]
heycam: Are any of these open issues where we need to decide on something?
16:19:46 [TabAtkins_]
ChrisL: Some are.
16:19:50 [TabAtkins_]
ChrisL: Let's start with tagged images.
16:20:02 [TabAtkins_]
ChrisL: It's possible to have an image that says it's in a profile but doesn't embed the profile.
16:20:07 [TabAtkins_]
ChrisL: Mostly they do embed their profile.
16:20:26 [TabAtkins_]
ChrisL: The spec says "you must apply the profile if it's available", defined as present, not malformed, etc.
16:20:36 [TabAtkins_]
ChrisL: If it's not present, that counts as not available, so that's okay.
16:20:40 [TabAtkins_]
heycam: What's the fallback?
16:20:44 [TabAtkins_]
ChrisL: Treat as sRGB.
16:20:52 [TabAtkins_]
ChrisL: We used to have something about overriding the profile.
16:20:58 [TabAtkins_]
ChrisL: Which was a weird thing to want to do.
16:21:03 [TabAtkins_]
ChrisL: Most people questioned the utility.
16:21:12 [TabAtkins_]
ChrisL: So, I've removed that.
16:21:19 [TabAtkins_]
heycam: In no-profile situations, is that a use-case?
16:21:32 [TabAtkins_]
ChrisL: Yeah, but we specifically say to treat as sRGB there.
16:21:43 [TabAtkins_]
ChrisL: Having looked, there's rarely an issue with mistagged images.
16:21:52 [TabAtkins_]
ChrisL: Authors or authoring tools almost always get it right.
16:22:11 [TabAtkins_]
ChrisL: The problem was that the spec took too much time talking about overriding the profile, and not enough about applying the profile that exists.
16:22:23 [TabAtkins_]
ChrisL: So I've beefed that up with some conformance requirements.
16:22:37 [TabAtkins_]
ChrisL: There used to be a 1.1 test for that, but since it wasn't testable we eventually removed it.
16:22:49 [TabAtkins_]
ChrisL: So I'll move it into the testsuite for this spec, since it is clearly defined.
16:23:00 [TabAtkins_]
ChrisL: The last thing on tagged images is about fallback images.
16:23:09 [TabAtkins_]
ChrisL: We do fallback for colors, but not really for images.
16:23:25 [TabAtkins_]
ChrisL: So maybe something like <switch>, but for some image attribute.
16:23:39 [TabAtkins_]
ChrisL: So if you don't do color matching, use this image; if you do, use this better image.
16:23:46 [TabAtkins_]
ChrisL: So what do we want to do here?
16:24:06 [TabAtkins_]
ChrisL: It's like a feature-string for this module.
16:24:13 [TabAtkins_]
heycam: I think that's reasonably simple to do.
16:24:28 [TabAtkins_]
vhardy: If you don't do color management, when would you design your content to switch to a different image?
16:24:37 [shepazu]
shepazu has joined #svg
16:24:44 [TabAtkins_]
ChrisL: If you do everything in sRGB, and you have a photo, you can convert that photo to sRGB, and it'll match.
16:24:55 [TabAtkins_]
ChrisL: But you'll lose out-of-gamut colors, which the cameras can capture.
16:25:09 [TabAtkins_]
ChrisL: It's easy to save the image as both high-quality and low-quality.
16:25:27 [TabAtkins_]
vhardy: And that's better than just ignoring the color profile and interpreting as sRGB?
16:25:48 [TabAtkins_]
ChrisL: No, you actually get different RGB values depending on your gamut. If you did that, all the colors would be wrong.
16:26:05 [TabAtkins_]
vhardy: So you actually end up with a lower-quality image if you just reinterpret the wide-gamut image.
16:26:08 [TabAtkins_]
ChrisL: That's right.
16:26:22 [TabAtkins_]
ChrisL: So should I just make up a feature-string?
16:26:48 [TabAtkins_]
shepazu: I have a suggestion, one moment...
16:26:53 [shepazu]
for feature strings, I propose the syntax "languageName.elementName.attributeNameOrPropertyName. attributeNameOrPropertyvalue" e.g. "svg.textPath.method.stretch"
16:27:44 [ChrisL]
so that is a very different sysntax to the 1.1 feaure strings
16:27:45 [ChrisL]
16:28:38 [shepazu]
could be
16:28:55 [TabAtkins_]
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.
16:29:48 [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
16:29:51 [shepazu]
16:30:15 [heycam]
ScribeNick: heycam
16:30:19 [heycam]
DS: we need something consistent
16:30:24 [heycam]
... so that's for attributes and properties
16:30:39 [heycam]
... for APIs we could say some other similar syntax
16:30:52 [TabAtkins_]
TabAtkins_ has joined #svg
16:31:01 [heycam]
ED: you can always test if the properties exist
16:31:10 [heycam]
DS: I think we should come up with a consistent feature string convention
16:31:58 [heycam]
ScribeNick: TabAtkins_
16:32:19 [heycam]
ScribeNick: heycam
16:32:26 [heycam]
CL: the next things is the section on definig colours
16:32:27 [TabAtkins_]
ScribeNick: TabAtkins_
16:32:30 [heycam]
... this is a complete replacement fro the section in 1.1
16:32:33 [heycam]
ScribeNick: heycam
16:32:41 [heycam]
... I define all the stuff, so there's a consistent grammar
16:32:51 [heycam]
... in the sRGB section there is a part I no longer agree with
16:33:09 [heycam]
... it says "sRGB" is predefined, and if you point a specific sRGB profile it's ignored
16:33:12 [heycam]
... but there is a need for that
16:33:22 [heycam]
... since there are differences between ICC versions of sRGB profiles
16:33:27 [heycam]
... so I'm going to remove that section
16:33:40 [heycam]
... there's also a need to specify what the transfer curve is for sRGB values that are outside teh gamut
16:33:48 [heycam]
... because the syntax allows that, negative values and values > 100%
16:33:54 [heycam]
... but we don't say what the gamma curve is beyond those points
16:34:12 [heycam]
... so I'm going to propose something there, that the curve is reflexive about the origin and follows a tangent at the end point
16:34:33 [heycam]
... 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
16:34:36 [heycam]
... that's sxRGB
16:34:40 [heycam]
... so I wonder whether we should add that
16:35:10 [heycam]
... the question about what to display with the wrong colour profile, I think that's why this exists
16:35:23 [heycam]
... if you use a wide space and interpret it witj sRGB you get a desaturated image
16:35:37 [heycam]
... but if you use sxRGB, then devices that don't understand it will treat it as sRGB and just clip
16:35:45 [heycam]
... the movie industry, bluray seems to be going for that sort of system
16:35:58 [heycam]
... 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
16:36:09 [heycam]
RC: when you talk about the transfer curve, what do you mean?
16:36:15 [heycam]
CL: it's the graph between the inptu and output
16:36:19 [heycam]
... sRGB has a particular transfer curve
16:36:27 [heycam]
... it's like a gamma 2.2 function, but a bit more complicated around the origin
16:36:36 [heycam]
... it's a graph of input values to light level output
16:36:43 [heycam]
RC: from RGB to device independent colour?
16:36:51 [heycam]
CL: no, from RGB to light levels you would measure with a probe
16:37:00 [heycam]
RC: so it's like a combination of two different profiles?
16:37:07 [heycam]
CL: no, it's the final stage when you're generating light at the end of the day
16:37:17 [heycam]
... the maximum level is white, the minimum is black
16:37:22 [heycam]
... the mid value isn't going to be 127
16:37:35 [heycam]
RC: do you as SVG need to worry about a transfer curve? isn't that handled by the monitor and graphics card?
16:37:42 [heycam]
CL: it does handle that...
16:37:50 [heycam]
RC: and you cannot give more than 100% to the graphcis card
16:38:16 [heycam]
CL: you know the CIE horse shoe diagram?
16:38:21 [heycam]
... and the triangle defines the primaries
16:38:32 [heycam]
... so now extend those lines of the triangle out, so instead of meeting at the points they cross and continue on
16:38:43 [heycam]
... you can now make colours outside the triangle, as long as you can use values < 0 or > 100%
16:38:48 [heycam]
... you can now specify the colours anywhere on the gamut
16:39:00 [heycam]
... if that's the physical device, and that's the last device in your chain, you can't go outside
16:39:12 [heycam]
... but if oyu're using it as an input, which might be composited, then you can specify values outside that
16:39:17 [heycam]
... and then would be converted to the rendering colour space
16:39:25 [heycam]
RC: but as soon as you go outside the gamut of the profile, things don't make sense any more?
16:39:32 [heycam]
... how could you ever measure and construct a profile for taht?
16:39:41 [heycam]
CL: you can measure it easily
16:39:52 [heycam]
RC: the profile just describes what the device is capable of displaying
16:41:26 [heycam]
[more discussion of out of gamut colours]
16:42:52 [TabAtkins_]
TabAtkins_ has joined #svg
16:43:16 [TabAtkins_]
ScribeNick: TabAtkins_
16:43:46 [TabAtkins_]
ChrisL: Next is uncontentious.
16:43:56 [TabAtkins_]
ChrisL: CSS3 Color adds hsl, hsla, rgba.
16:44:13 [TabAtkins_]
ChrisL: In CIELAB you need to specify the whitepoint.
16:44:58 [TabAtkins_]
TabAtkins_: How does SVG handle transparent colors?
16:45:48 [TabAtkins_]
ChrisL: The opacity property combines with the color's own opacity.
16:46:02 [TabAtkins_]
TabAtkins_: What about transitions between colors, like in linearGradient?
16:46:18 [TabAtkins_]
ChrisL: That should be handle by color-interpolation, likely expanded in the manner you suggested.
16:46:56 [TabAtkins_]
heycam: SVG2 is going to reference CSS3 Color, I thought?
16:47:10 [TabAtkins_]
ChrisL: SVG Color will also reference CSS3 Color.
16:47:26 [TabAtkins_]
ChrisL: next is rendering-intent.
16:47:54 [TabAtkins_]
ChrisL: 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.
16:48:10 [TabAtkins_]
ChrisL: But the outside colors need to be manipulated somehow. How you do this depends on what you want to do with the result.
16:48:18 [TabAtkins_]
ChrisL: In the ICC model, there are four different rendering intents.
16:49:13 [TabAtkins_]
ChrisL: 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.
16:49:43 [TabAtkins_]
ChrisL: 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.
16:50:31 [TabAtkins_]
ChrisL: In SVG 1.1, you can specify a color using ICC.
16:50:41 [TabAtkins_]
ChrisL: You get an sRGB back, but still.
16:50:52 [TabAtkins_]
ChrisL: This guy is working on desktop publishing which goes back to color-managed printing.
16:51:01 [TabAtkins_]
ChrisL: So he's interested in what happens to rendering intent.
16:51:16 [TabAtkins_]
ChrisL: in SVG the only compositing space is sRGB.
16:51:37 [TabAtkins_]
ChrisL: So you convert your CMYK to sRGB, composite, then go back to CMYK for the printer, and you've lost your rendering intent.
16:51:45 [TabAtkins_]
ChrisL: So right now it's an open issue how to preserve that.
16:52:03 [TabAtkins_]
ChrisL: It's unclear in 1.1 whether colors which have opacity are treated differently than solid colors.
16:52:17 [TabAtkins_]
ChrisL: So you can (a) imagine that everything is composited (even if a solid color)
16:52:36 [TabAtkins_]
ChrisL: or (b) only composite if you need to, so opaque colors will be preserved exactly with their rendering intent.
16:52:44 [TabAtkins_]
ChrisL: That has implications with anti-aliasing, etc.
16:53:08 [TabAtkins_]
ChrisL: There may be need for different rendering intents on different elements (photos want perceptual, solid colors want relative-colorimetric).
16:53:29 [TabAtkins_]
ChrisL: 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.
16:53:48 [TabAtkins_]
cabanier: If PDF and PS, you tag the element with the rendering intent.
16:55:18 [cabanier]
cabanier: in pdf and postscript, the document, the printer and the device can all specify the default rendering intent
16:56:05 [TabAtkins_]
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.
16:56:13 [tbah]
tbah has joined #svg
16:56:18 [TabAtkins_]
ChrisL: So imaging you have two color-spaces, and they're mapped to a 3d diagram (black on bottom, white on top)
16:56:24 [cabanier]
in addition to that, elements can override the default rendering to get results that are applicable to that content
16:56:26 [TabAtkins_]
ChrisL: Imagine a vector from black to white.
16:56:47 [TabAtkins_]
ChrisL: 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.
16:57:04 [TabAtkins_]
ChrisL: Similarly for black-points, with different color-spaces having different "deepest black".
16:57:16 [TabAtkins_]
ChrisL: It's not clear to me how to specify it.
16:57:21 [TabAtkins_]
ChrisL: But people have asked for it.
16:57:36 [TabAtkins_]
vhardy: Are there precedents we can look at?
16:58:01 [TabAtkins_]
ChrisL: When ICC updated sRGB to version 4, they produced two profiles, one with and one without blackpoint compensation.
16:58:17 [TabAtkins_]
ChrisL: And in Photoshop, the dialog box has a checkbox for blackpoint compensation when converting between colorspaces.
16:58:38 [TabAtkins_]
ChrisL: So if it's purely something for the output stage, it should be defined in the device profile (which SVG doesn't specify).
16:58:48 [TabAtkins_]
ChrisL: If that's the only place you need, SVG doesn't need to say anything.
16:59:07 [TabAtkins_]
ChrisL: 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.
16:59:24 [TabAtkins_]
vhardy: A use-case for input is you taking a picture and knowing that the blackpoint is different?
16:59:59 [TabAtkins_]
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.
17:00:03 [TabAtkins_]
cabanier: PDF defines it on the input.
17:00:23 [TabAtkins_]
ChrisL: So I suggest marking an issue and waiting for feedback.
17:00:58 [TabAtkins_]
cabanier: Whitepoint and blackpoint mapping are used on calibrateRGB colorspace.
17:01:23 [TabAtkins_]
ChrisL: last issue is preserving black.
17:01:46 [TabAtkins_]
ChrisL: For example, in ICC if you specify icc(0,0,0,1), color-management systems tend to have a switch that specially treats that value.
17:02:06 [TabAtkins_]
ChrisL: So even if the system does color-manipulation normally, that one color will instead stay solid, total black.
17:02:18 [TabAtkins_]
17:02:32 [TabAtkins_]
ChrisL: This is so black text stays pure black and doesn't mix in other colors.
17:02:45 [TabAtkins_]
ChrisL: So, similarly, we need to see if we need it, and see if it's an input or output feature.
17:02:58 [TabAtkins_]
cabanier: We have it in InDesign, and it's an output feature there.
17:03:38 [TabAtkins_]
cabanier: So we have some special cases there again; you don't want to preserve black on an image.
17:03:51 [TabAtkins_]
ChrisL: So that's basically actually being an input feature.
17:04:08 [Zakim]
17:04:37 [Zakim]
17:05:08 [TabAtkins_]
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?
17:05:09 [anne]
anne has joined #svg
17:05:17 [anne]
anne has left #svg
17:05:31 [TabAtkins_]
heycam: Also, if you have some colored shapes which are composited together, and you happen to get black out of that, should that be preservable?
17:06:48 [TabAtkins_]
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.
17:07:25 [TabAtkins_]
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.
17:08:29 [TabAtkins_]
TabAtkins_: So if you composite a partially-transparent gradient over a black rectangle, you wouldn't preserve the black in it.
17:09:01 [TabAtkins_]
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.
17:10:18 [TabAtkins_]
TabAtkins_: So it sounds like we can do this automatically at the end, and thus don't need a property for it.
17:10:31 [TabAtkins_]
heycam: And in PDF, it's not controllable; it just happens automatically.
17:11:09 [TabAtkins_]
ChrisL: That's it for Color. I'll do another round of edits, then announce it for review and feedback.
17:11:22 [TabAtkins_]
heycam: Is the plan to resolve all these issues and then publish, or did you want to publish before that.
17:11:45 [TabAtkins_]
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.
17:12:04 [TabAtkins_]
ChrisL: So after we get feedback, we can clean it up.
17:12:22 [TabAtkins_]
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?
17:12:42 [TabAtkins_]
ChrisL: There was some color management in CSS earlier, but there wasn't impl interest so it was removed.
17:12:56 [TabAtkins_]
ChrisL: This is mainly requested by people who want to use SVG and then go straight to print.
17:13:02 [cabanier]
cabanier has joined #svg
17:13:15 [TabAtkins_]
ChrisL: So we'll see print industries implement it first, and then it'll gradually bleed over.
17:13:25 [TabAtkins_]
ChrisL: So right now it's good to have it defined just here in SVG.
17:13:33 [thorton]
thorton has joined #svg
17:13:33 [TabAtkins_]
ChrisL: I think it'll be an optional module for SVG2 right now.
17:13:42 [TabAtkins_]
ChrisL: Actually, one more issue to discuss.
17:13:47 [TabAtkins_]
ChrisL: How are we doing tests for SVG2?
17:13:56 [TabAtkins_]
ChrisL: I would like to start putting together some tests for these features.
17:14:10 [TabAtkins_]
ChrisL: Are we doing reftests, or what?
17:14:21 [TabAtkins_]
ed: Unless you can test things with script, I'd go with reftests.
17:14:23 [vhardy] (see test section)
17:14:37 [TabAtkins_]
ChrisL: Some of them I can script test, so that's fine.
17:14:52 [TabAtkins_]
ChrisL: Are we using plinss's test harness?
17:14:55 [TabAtkins_]
shepazu: That's the plan.
17:15:14 [TabAtkins_]
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.
17:15:25 [TabAtkins_]
heycam: It should be a simple matter to convert formats when we need to.
17:15:29 [TabAtkins_]
vhardy: Couple of questions.
17:15:52 [TabAtkins_]
vhardy: Re tagged images, you said overriding profiles didn't make much sense.
17:15:56 [TabAtkins_]
vhardy: What's the history of this feature?
17:16:04 [TabAtkins_]
ChrisL: i think it was there from very early on. It was in SVG Print.
17:16:28 [TabAtkins_]
ChrisL: 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.
17:16:47 [TabAtkins_]
ChrisL: 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.
17:16:53 [TabAtkins_]
ChrisL: So it's just not a problem today.
17:17:05 [TabAtkins_]
vhardy: So it's not a question of someone needing a feature who happens to not be around now?
17:17:08 [TabAtkins_]
ChrisL: No.
17:17:18 [TabAtkins_]
vhardy: Ok. Is it okay that we didn't actively capture resolutions today?
17:17:28 [TabAtkins_]
ChrisL: Yes. I have notes, and I'll bring questions back to the ML.
17:17:53 [TabAtkins_]
Topic: SVG Vector Effects
17:17:56 [ChrisL]
17:18:04 [TabAtkins_]
ChrisL: I have two questions.
17:18:31 [TabAtkins_]
ChrisL: The first feature on the page started in vector effects, and I request that we move it out into SVG proper.
17:18:47 [TabAtkins_]
ChrisL: Currently we have currentColor, which takes the current animated value of the color property.
17:18:58 [TabAtkins_]
ChrisL: So this is well-defined tree-structure inheritance.
17:19:09 [TabAtkins_]
ChrisL: So I can say fill:currentColor or whatever.
17:19:19 [shepazu]
17:19:28 [TabAtkins_]
ChrisL: So I propose taking this as the basis and expanding it to six values.
17:19:30 [shepazu]
17:19:41 [TabAtkins_]
ChrisL: currentColor, currentFillPaint, and currentStrokePaint.
17:19:57 [TabAtkins_]
ChrisL: This lets you do the common thing of "how do I do markers that are the same color as the line they're on".
17:20:15 [TabAtkins_]
ChrisL: And then three more which are identical, but rather than coming from the point in the tree, they come from use.
17:20:29 [TabAtkins_]
ChrisL: So you can use this in a <symbol>, and it'll pick up different values from each place it's used.
17:20:53 [TabAtkins_]
ChrisL: 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.
17:21:11 [TabAtkins_]
heycam: If we can use this to remove the magical inheritance, we should try to kill the magic handwaving.
17:21:17 [TabAtkins_]
ChrisL: Yes, I think we can do this.
17:21:23 [TabAtkins_]
heycam: And I think this is more obvious.
17:22:40 [heycam]
ScribeNick: heycam
17:22:44 [heycam]
CL: there are two sets of values
17:22:52 [heycam]
... one is "on define" and the other is "on use"
17:23:04 [heycam]
CM: ok
17:23:20 [heycam]
CL: I think these are reasonable
17:23:29 [heycam]
... I want to propose this, can we accept it?
17:23:41 [heycam]
CC: no objection, just a comment
17:23:52 [heycam]
... the currentColor is already something that is not that simple to implement when you consider inheritance, animations
17:23:57 [TabAtkin1_]
TabAtkin1_ has joined #svg
17:23:59 [heycam]
... so adding new values means adding complexity
17:24:06 [heycam]
... I understand the use cases, just pointing out that it's complex
17:24:09 [heycam]
CL: I understand that
17:24:20 [heycam]
... CSS uses inheritance all over the place, so that ship has already sailed
17:24:39 [heycam]
... this is going to be much simpler than the magical inheritance into use
17:26:01 [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.
17:26:06 [heycam]
RESOLUTION: We will add new paint values currentFillPaint, currentStrokePaint etc. to SVG 2
17:26:21 [heycam]
ScribeNick: TabAtkin1_
17:26:34 [TabAtkin1_]
ACTION: ChrisL to write up spec text for currentFillPaint, etc.
17:26:35 [trackbot]
Created ACTION-3094 - Write up spec text for currentFillPaint, etc. [on Chris Lilley - due 2011-08-05].
17:26:55 [TabAtkin1_]
vhardy: Since we have a req document for SVG2, perhaps we can annotate for things with resolutions as hard requirements.
17:27:09 [TabAtkin1_]
ed: Sounds like going through the last few f2f and tracker.
17:28:33 [TabAtkin1_]
ACTION: ed to go through the last few f2f minutes to find resolutions for SVG2 items, and add them to the wiki page.
17:28:33 [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].
17:28:47 [TabAtkin1_]
ChrisL: Second things is about constructive geometry.
17:29:01 [TabAtkin1_]
ChrisL: Basicall union and intersection to produce new shapes.
17:29:05 [TabAtkin1_]
ChrisL: Widely used in 3d.
17:29:27 [TabAtkin1_]
ChrisL: It's being criticized as being computationally intensive, and as being possible non-interoperable as getting slightly different results between impls.
17:29:33 [TabAtkin1_]
ChrisL: Same rendering, but different underlying nodes.
17:29:38 [TabAtkin1_]
ChrisL: These are valid concerns.
17:29:49 [TabAtkin1_]
ChrisL: Though, looking at the sbasic library, it does this.
17:29:56 [TabAtkin1_]
17:30:18 [ChrisL]
17:30:29 [TabAtkin1_]
ChrisL: And it apparently isn't particularly computationally intensive.
17:30:48 [TabAtkin1_]
ChrisL: So, while accepting that we do have some problems, really the whole of VE gets its value from these things.
17:31:12 [TabAtkin1_]
ChrisL: You can still do some other useful things, but really the main expressive power is being able to union/intersect geometry here.
17:31:50 [TabAtkin1_]
ChrisL: 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.
17:32:03 [TabAtkin1_]
ChrisL: So I'd like to resolve one way or another on whether we're going to pursue it.
17:32:17 [TabAtkin1_]
vhardy: Can you elaborate on the criticisms?
17:32:26 [TabAtkin1_]
ChrisL: I think Alex Danilo said it was heavily unspecified.
17:32:44 [TabAtkin1_]
ChrisL: 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?
17:33:17 [TabAtkin1_]
heycam: The fact that it doesn't guarantee particular paths... we already have that with normalized path seglist.
17:33:58 [TabAtkin1_]
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.
17:34:07 [TabAtkin1_]
ChrisL: Unless we put some pretty rigid constraints on the algorithms.
17:34:29 [TabAtkin1_]
vhardy: I think that it's a very useful feature. It's in Illustrator, and is used all the time.
17:34:37 [TabAtkin1_]
vhardy: For the platform it's a useful capability.
17:34:56 [TabAtkin1_]
vhardy: So I think our process is to go ahead and spec, and deal with impl feedback as it comes in.
17:35:14 [TabAtkin1_]
heycam: One of Chris's questions was "will this be easy to specify?
17:35:34 [TabAtkin1_]
heycam: So I guess we just need someone to try.
17:35:42 [TabAtkin1_]
cabanier: Is this a scripting API or declarative?
17:35:56 [TabAtkin1_]
heycam: Declarative, though there may be APIs layered on top later.
17:36:04 [TabAtkin1_]
ChrisL: Yeah, like asking for a copy of the path so you can use it later.
17:36:19 [TabAtkin1_]
heycam: And eventually being able to get a path and call .union(otherpath) would be useful later.
17:36:31 [TabAtkin1_]
ChrisL: So I'm hearing that it sounds useful, we should proceed and see if we run into problems.
17:36:41 [TabAtkin1_]
heycam: I was one of those that had concerns.
17:36:58 [TabAtkin1_]
heycam: obviously authoring tools can do it performantly (because they do it)
17:37:13 [TabAtkin1_]
ChrisL: Yeah, and now we know how some of them do it (convert everything to sbasis curves and do magic).
17:37:57 [TabAtkin1_]
cyril_: So the intersection always decomposes into a normal path. Is there any real benefit over doing this totally in authoring tools?
17:38:07 [TabAtkin1_]
cyril_: Beyond just basic geom semantics.
17:38:32 [TabAtkin1_]
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.
17:38:50 [TabAtkin1_]
cyril_: What about filesize benefits?
17:38:54 [TabAtkin1_]
cabanier: Sometimes smaller.
17:39:34 [TabAtkin1_]
shepazu: The big benefit is doing this in the browser. Moving things out of the authoring environment into the browser is a good thing.
17:39:47 [TabAtkin1_]
shepazu: I think another thing we don't do in VE right now is, it doesn't have an API.
17:39:58 [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
17:40:03 [TabAtkin1_]
shepazu: So anything available through the element-based syntax should also be doable via API.
17:41:01 [TabAtkin1_]
shepazu: Then we can also do this in Canvas, frex.
17:42:21 [TabAtkin1_]
heycam: I think the arguments for doing VE are similar to the arguments for doing text warping, etc.
17:42:56 [TabAtkin1_]
RESOLUTION: Keep constructive geometry operations in VE and see if it's possible.
17:43:11 [TabAtkin1_]
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.
17:43:31 [TabAtkin1_]
shepazu: So is this part of SVG2, or is it part of a module?
17:44:03 [ChrisL]
currently its edited as a module
17:44:47 [TabAtkin1_]
heycam: I think keep it as a module for now. It gives it better visibility.
17:44:50 [ChrisL]
it can always be merged later
17:45:20 [Zakim]
17:45:30 [TabAtkin1_]
<br duration=15min>
17:49:33 [tbah]
OK, I'll call in anyway. The girls are in bed. Peace has returned.
17:50:20 [Zakim]
disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)16:09Z
17:50:24 [Zakim]
Team_(svg)16:09Z has ended
17:50:26 [Zakim]
Attendees were +1.206.675.aaaa, ChrisL
18:10:09 [ed]
Zakim, room for 3?
18:10:11 [Zakim]
ok, ed; conference Team_(svg)18:10Z scheduled with code 26631 (CONF1) for 60 minutes until 1910Z
18:10:32 [Zakim]
Team_(svg)18:10Z has now started
18:10:39 [Zakim]
+ +1.206.675.aaaa
18:11:14 [tbah]
tbah has joined #svg
18:11:41 [Zakim]
18:12:16 [vhardy]
ScribeNick: vhardy
18:12:22 [vhardy]
Topic: SVG Compositing
18:12:41 [vhardy]
Topic: Advanced Gradients
18:13:22 [tbah]
18:13:26 [vhardy]
tav: I have taken what was proposed as a structure for test-gradients and patched InkScape to use that
18:13:34 [vhardy]
18:13:56 [cabanier]
cabanier has joined #svg
18:14:02 [vhardy]
tav: I added this in my private copy of InkScape.
18:14:03 [Zakim]
18:14:33 [vhardy]
tab: I have also Coons patch mesh gradients in Canvas
18:14:52 [vhardy]
tav: So you have a way to defining them?
18:14:58 [vhardy]
tab: yes, and an implementation.
18:15:06 [TabAtkin1_]
Apropos of text stroking,
18:15:09 [vhardy]
tab: it is a JS impl
18:15:11 [TabAtkin1_]
18:15:37 [vhardy]
heycam: I came up with a syntax and then got feedback from tab
18:16:08 [vhardy]
tav: I have produced some interseting gradients.
18:16:18 [vhardy]
tav: cairo has bugs with that type of gradients.
18:16:28 [vhardy]
tav: I get crashes in some cases.
18:16:39 [vhardy]
tav: you can see the definition of the gradients in the code sample.
18:17:01 [vhardy]
tav: there is a <meshGradient>, a <meshRow> and a <meshPatch>
18:17:22 [vhardy]
... then there is a sphere with four patches
18:17:38 [vhardy]
... then there is conical gradients that can be done with meshes as well.
18:17:50 [vhardy]
... done with one zero-length size.
18:18:11 [vhardy]
... then a 6x6 patch mesh gradient.
18:18:17 [vhardy]
.. the performance is good enough.
18:18:27 [tbah]
18:19:00 [vhardy]
... the gray box half way down is the syntax proposed.
18:19:20 [vhardy]
... the way it is defined is an array of patches aligned in rows.
18:19:28 [ChrisL]
like a table
18:19:52 [vhardy]
.. ther eis a <meshRow> which defines the begining and then a <meshPatch> with has four stops. The stops have a stop-path.
18:20:10 [vhardy]
... you could have a curve or a line. Cairo supports curveto and lineto
18:20:26 [vhardy]
... you need a Bezier curve. If you need other curves, you need to translate to Bezier.
18:20:33 [vhardy]
shepazu: this seems pretty verbose.
18:20:46 [vhardy]
... I am not sure how to make it more concise.
18:21:05 [vhardy]
tav: you could combine the paths into one and then you could specify the colors for the corners.
18:21:12 [vhardy]
tav: I think I like this better.
18:21:21 [vhardy]
tab: it is always a quad.
18:21:40 [vhardy]
tav: if the last two points coincide, you could skip them.
18:22:30 [vhardy]
... 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.
18:22:43 [vhardy]
cabanier: can you have disjoined patches?
18:22:46 [vhardy]
tav: yes.
18:23:06 [vhardy]
18:23:31 [vhardy]
tav: if you want to be able to edit that, then you start with a single patch and then start dividing.
18:23:57 [vhardy]
tav: the second patch is attached to the right of the first patch.
18:25:02 [vhardy]
tav: you can distort the array any way you want, like in the conical gradient example.
18:25:19 [vhardy]
tav: conceptually, you need an array, top, left right.
18:25:55 [vhardy]
tav: Moving on to <!-- New row --> in the gray section.
18:26:20 [vhardy]
tav: note that the first path is ommited because it is taken from the bottom patch of the patch above.
18:26:53 [vhardy]
tav: next patch, you only need to specify 2 of the paths, because the top and left path are coming from the previously specified colors.
18:27:06 [vhardy]
heycam: if you specify a color which you already know?
18:27:10 [vhardy]
tav: it is ignored.
18:27:43 [vhardy]
tav: then I list changes from what Tab had proposed.
18:28:26 [vhardy]
heycam: I am not sure stop-path is the best name. Attributes with a dash are properties, e..g, stop-color is a property.
18:28:50 [vhardy]
heycam: it should probably be path.
18:28:55 [vhardy]
vhardy: or 'd'
18:29:42 [vhardy]
RESOLUTION: rename stop-path to 'd' or 'path'
18:30:10 [vhardy]
shepazu: since it is not exactly the same syntax as 'd', it probably better to use 'path'
18:30:37 [vhardy]
shepazu: I wonder if we are going to have Catmull Rom curves, it might be useful to have that.
18:30:52 [vhardy]
tab: we should allow any given path segment that <path> has.
18:30:59 [ChrisL]
yeah but if libraries are constraind to bezier paths then that is what you would need to use
18:31:35 [vhardy]
cyril: how do you use stop-opacity?
18:31:47 [vhardy]
tav: yes, you can. I have not done an example, but the Cairo code allows it.
18:32:03 [vhardy]
cyril: do you have spread and pad methods.
18:32:34 [vhardy]
cyril: I think it is not a good idea.
18:32:42 [vhardy]
cyril: how would you use it?
18:32:56 [vhardy]
tab: it feels more like a geometric primitive, and not a fill?
18:33:18 [vhardy]
tav: in the last example I did, it fills the rectangle completely.
18:33:46 [vhardy]
tav: the edges are outside the rectangle.
18:33:58 [vhardy]
cyril: what is the coordinate system for the mesh?
18:34:03 [vhardy]
tav: same as other gradients.
18:34:13 [ChrisL]
18:34:39 [vhardy]
cyril: so what about padding and reflection?
18:34:49 [vhardy]
tav: how do you reflect somethign that is not a straight line?
18:34:58 [vhardy]
tab: there is no notion of padding and reflecting.
18:35:08 [vhardy]
cabanier: how would you do that?
18:36:08 [vhardy]
tab: there is a possibility to extend the gradient outside the edges of the patch, by reflecting the mesh.
18:37:02 [vhardy]
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.
18:37:18 [vhardy]
cyril: don't you want the geometry of the shape to match the mesh's geometry?
18:37:29 [vhardy]
tab: yes, the mesh would match the geometry.
18:38:25 [vhardy]
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.
18:38:40 [vhardy]
tab: I thought of that initially.
18:39:32 [vhardy]
18:39:47 [vhardy]
tab: the last example (the lamp head), looks like it should be a geometry.
18:40:12 [vhardy]
tav: the lamp is one mesh gradient defined with many small patches. Four rows of patches.
18:40:25 [vhardy]
tav: this shows how an authoring tool would work.
18:41:03 [vhardy]
tav: the mesh structure is important to be able to edit the mesh easily in a tool.
18:41:47 [vhardy]
tav: Illustrator only does arrays for meshes as well.
18:42:47 [vhardy]
cabanier: using an array of patches is the most common use case by far. PDF has more capabilities, but they are less commonly used.
18:43:31 [vhardy]
cabanier: we have techniques to compress the mesh data.
18:43:43 [vhardy]
cabanier: is this needed in SVG?
18:43:53 [vhardy]
tab: yes, it is commonly used in authoring tools.
18:44:02 [vhardy]
tab: should it be a geometric primitive?
18:44:43 [vhardy]
tab: I could see the path warping used for other things (warping shapes, text, images, four color interpolation).
18:44:57 [vhardy]
tab: the mesh could be a geometric primitive and then take a fill of its own.
18:45:12 [vhardy]
heycam: we cannot do the square patch gradient right now.
18:45:23 [vhardy]
tab: we would need to define a new gradient for that.
18:45:56 [vhardy]
heycam: I am not sure. Some are very object specific, some are not.
18:46:04 [vhardy]
.. e.g., a rainbow.
18:46:20 [vhardy]
tab: yes, I can see that. But very often, you want to have the mesh and the object geometry match.
18:46:33 [vhardy]
heycam: what about having a patch reference the outside edge of a path.
18:47:21 [vhardy]
cabanier: that does not always work, like in the mesh wild example.
18:47:37 [vhardy]
heycam: yes, that would not work.
18:48:45 [vhardy]
shepazu: we ran into this with other case.
18:48:50 [vhardy]
18:49:31 [vhardy]
heycam: there seem to be different use cases, one where it is generic and reusable and one where the mesh matches the object.
18:49:44 [vhardy]
... neither way seems exactly right.
18:49:50 [vhardy]
... what about PDF?
18:50:05 [vhardy]
cabanier: for meshes, there is a fill operator that does not rely on having a path.
18:50:21 [vhardy]
... so the mesh is an object and you cannot stroke it.
18:50:44 [vhardy]
... there is a second way where it is like a paint server.
18:50:58 [vhardy]
... one is a geometric primitive and the second way is a paint server.
18:51:46 [vhardy]
tab: It could be done where the paint server renders if not in a <def> but can be referenced like other paint servers.
18:52:22 [vhardy]
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.
18:52:35 [vhardy]
... you need to specify additional information.
18:52:54 [vhardy]
... like transform, coordinate space.
18:53:05 [ed]
18:53:21 [vhardy]
heycam: I like tab's idea.
18:55:22 [vhardy]
RESOLUTION: mesh gradients are accepted by the WG for SVG 2.0.
18:56:43 [Zakim]
18:56:53 [vhardy]
ACTION: tbah to update the coon's mesh proposal to make it both a geometric primitive and a paint server.
18:56:54 [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].
18:57:29 [tbah]
I just got kicked out.. what was the conference code?
18:57:42 [heycam]
Zakim, code?
18:57:42 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200, heycam
18:58:50 [Zakim]
+ +39.537.7.aabb
18:59:13 [Zakim]
18:59:53 [Zakim]
19:00:11 [ChrisL]
i got kicked out as well
19:00:56 [vhardy]
Topic: current gradient issues.
19:01:04 [heycam]
19:01:53 [tbah]
zakim +39.537 is me
19:02:18 [vhardy]
19:02:30 [tbah]
zakim, +39.537 is me
19:02:30 [Zakim]
+tbah; got it
19:03:36 [cyril_]
19:04:37 [vhardy]
ed: this behaves differently in all browsers
19:06:01 [ed]
<radialGradient id="myRadGrad" fx="80%" r="10%" spreadMethod="reflect" >
19:07:14 [vhardy]
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.
19:07:55 [ChrisL]
zakim, mute doug as usual
19:07:55 [Zakim]
I don't understand 'mute doug as usual', ChrisL
19:07:59 [vhardy]
cyril: the issue is when the focal point reaches the edge of the gradial gradient
19:08:04 [ChrisL]
more is the pity, zakim
19:08:17 [cyril_]
19:08:28 [ed]
19:09:06 [vhardy]
ed: FF has the most sensible interpretation.
19:11:57 [ChrisL]
so I see lack of sub-pixel precision in the opera rendering
19:13:38 [vhardy]
ed: if we want interoperable behavior, this needs to be clarified in the spec.
19:13:51 [vhardy]
heycam: it seems like the Firefox behavior looks the most reasonable.
19:14:03 [vhardy]
ed: may be some people would like something different.
19:15:04 [vhardy]
vhardy: is that really a spec. problem?
19:15:22 [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."
19:15:33 [ed]
this is for spreadMethod on radialGradient
19:15:38 [vhardy]
ed: yes, because the spec. for reflection on radialGradients is not precise enough, it only says to do the same thing as linear.
19:16:15 [ed]
this is what it says for spreadMethod on linearGradient:
19:16:21 [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
19:16:21 [ed]
c. continuously until the target region is filled.
19:16:21 [ed]
If the attribute is not specified, the effect is as if a value of 'pad' were specified."
19:20:45 [vhardy]
(group experimenting with the example)
19:23:15 [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’."
19:25:59 [vhardy]
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.
19:27:45 [vhardy]
tab: for the same problem with linear gradients in CSS, we resolved to have the average color of all the gradient stops.
19:29:08 [vhardy]
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.
19:30:50 [ed]
s/the average/the weighted (by offset) average/
19:30:55 [vhardy]
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.
19:30:55 [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].
19:31:40 [vhardy]
Topic: fr attribute on radialGradients
19:33:24 [vhardy]
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.
19:34:45 [vhardy]
ed: fr would define where you would hav the zero offset for stops.
19:36:06 [vhardy]
RESOLUTION: add an fr attribute to <radialGradient> for SVG 2.0.
19:36:34 [vhardy]
ACTION: ed to provide spec. wording for the fr attribute on <radialGradient>
19:36:35 [trackbot]
Created ACTION-3098 - Provide spec. wording for the fr attribute on <radialGradient> [on Erik Dahlström - due 2011-08-05].
19:36:43 [vhardy]
19:36:57 [Zakim]
19:37:06 [Zakim]
19:42:06 [Zakim]
disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)18:10Z
19:42:10 [Zakim]
Team_(svg)18:10Z has ended
19:42:12 [Zakim]
Attendees were +1.206.675.aaaa, tbah, ChrisL, +39.537.7.aabb
19:58:31 [karl]
karl has joined #svg
20:15:35 [karl]
karl has joined #svg
20:49:17 [jenyu]
jenyu has joined #svg
20:49:54 [heycam]
ScribeNick: jenyu
20:50:27 [jenyu]
topic: Compositing
20:51:08 [cyril_]
20:52:41 [cabanier]
cabanier has joined #svg
20:52:51 [cabanier]
comments from Alex: The main problem I see now (after
20:52:51 [cabanier]
all this time not bothering to notice) is that we've mixed two orthogonal
20:52:51 [cabanier]
things into the one property.
20:52:51 [cabanier]
P-D dictates the combination logic for each of the 4 alpha blend
20:52:51 [cabanier]
areas, namely src, dst, src&dst, no src or dst as the diagram at the top
20:52:52 [cabanier]
of the compositing spec. shows (the big square with coloured areas - yellow,
20:52:55 [cabanier]
mixed, blue and white).
20:52:56 [cabanier]
What the blending modes do is apply only to the top triangle which
20:52:58 [cabanier]
manages how you mix src & dst. In all the blend modes, we are assuming
20:53:00 [cabanier]
P-D src over which is compatible with PDF, etc.
20:53:02 [cabanier]
But the problem I see now is that's too restrictive. It may well
20:53:04 [cabanier]
be nice to use an 'in' operator to restrict the effect to the intersection
20:53:06 [cabanier]
of two objects but have them combined with a blend mode (like overlay, etc.)
20:53:08 [cabanier]
That seems an obvious thing to do, but there is no way to do it as the
20:53:11 [cabanier]
spec. is written now. We've overloaded 'comp-op' and this isn't possible.
20:53:12 [cabanier]
So the only way to achieve that is to use a clip path and clip
20:53:14 [cabanier]
one object against the other and use the correct comp-op to get the
20:53:17 [cabanier]
color mix correct which is quite a hack.
20:53:19 [cabanier]
In hindsight I'm a bit surprised this hasn't been noticed before
20:53:20 [cabanier]
but that's most likely due to lack of implementations and scrutiny.
20:55:18 [sylvaing]
sylvaing has joined #svg
21:00:13 [jenyu]
cabanier: question: do we keep the adobe blending modes (aligned with current spec) or porter duff?
21:00:23 [jenyu]
cabanier: porter duff seems too primitive for SVG
21:02:41 [cyril_]
adobe blending modes:
21:06:05 [jenyu]
: what's the hardware support for the blend modes like?
21:06:25 [jenyu]
cabanier: adobe modes can be done in hardware; pixel shaders are always possible anyway
21:06:52 [cyril_]
chapter 11, table 136, in
21:07:38 [jwatt_]
jwatt_ has joined #svg
21:08:29 [jenyu]
heycam: can you do these with filters? there's feComposite and feBlend
21:09:02 [vhardy]
21:09:05 [jenyu]
vhardy: we should be consistent in our blend modes in filters and compositing
21:10:11 [jwatt_]
jwatt_ has joined #svg
21:11:03 [jenyu]
cabanier: alex proposed that we should remove the underspecified compositing features and spend time carefully specifying the needed features
21:12:05 [jenyu]
cabanier: you can achieve effects with filters but it makes it hard to read
21:12:42 [jenyu]
heycam: given that we are introducing the filter property, does it make sense to make compositing a shorthand to a filter?
21:14:15 [jenyu]
vhardy: describing it as a comp-op is a much clearer model than using filters
21:15:01 [ChrisL]
ChrisL has joined #svg
21:15:02 [jenyu]
heycam: what's the difference between blend and general compositing operations?
21:17:11 [jenyu]
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
21:17:20 [vhardy]
21:19:55 [Zakim]
Zakim has left #svg
21:21:33 [jenyu]
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
21:22:13 [jenyu]
cyril: is it implicit that compositing operations are chained?
21:22:45 [sgalineau]
sgalineau has joined #svg
21:23:08 [jenyu]
vhardy: the painting algorithm is followed, so yes comp-ops apply in a sequential chain
21:25:35 [ChrisL]
rrsagent, here
21:25:35 [RRSAgent]
21:28:48 [jenyu]
cabanier/cyril: [drawing nested g elements on the board with comp-op property]
21:30:04 [jenyu]
vhardy: [drawing more nested groups and shapes on the board, some with comp-op]
21:31:37 [jenyu]
vhardy: [top-level group contains enable-background="new" for the comp-op operations in its child elements]
21:33:25 [jwatt_]
jwatt_ has joined #svg
21:34:10 [sylvaing]
sylvaing has joined #svg
21:40:39 [jenyu]
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?
21:41:11 [jenyu]
cabanier: this was discussed previously. peter has a use case for it and feels strongly about it
21:43:45 [jenyu]
heycam: it will be hard to reach a resolution. not many people understand this completely
21:43:55 [jenyu]
cabanier: the pdf file describes this in detail (which is very similar to compositing described in the SVG spec)
21:46:48 [jenyu]
cabanier: the knock-out property seems ill-defined. the formulas are not quite correct
21:48:17 [jenyu]
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?
21:52:17 [jenyu]
action: Give a description of how porter-duff behaves differently from blend modes (group invariance)
21:52:17 [trackbot]
Sorry, couldn't find user - Give
21:53:12 [jenyu]
action: cabanier to Give a description of how porter-duff behaves differently from blend modes (group invariance)
21:53:12 [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].
21:53:54 [jwatt_]
jwatt_ has joined #svg
21:55:07 [Zakim]
Zakim has joined #svg
21:55:12 [heycam]
Zakim, room for 3?
21:55:13 [Zakim]
ok, heycam; conference Team_(svg)21:55Z scheduled with code 26631 (CONF1) for 60 minutes until 2255Z
21:55:19 [Zakim]
Team_(svg)21:55Z has now started
21:55:26 [Zakim]
+ +1.206.675.aaaa
21:55:54 [ed]
21:56:23 [Zakim]
21:56:29 [jenyu]
topic: css dependencies
21:57:03 [ChrisL]
21:58:22 [cabanier]
cabanier has joined #svg
22:00:23 [jenyu]
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)
22:00:44 [jenyu]
ed: the clip property is another one that changed from CSS2 and 2.1
22:02:02 [sylvaing]
sylvaing has joined #svg
22:02:05 [jenyu]
ed: browsers aren't interoperable on the clip property so no one uses it anyway
22:02:56 [jenyu]
resolution: SVG2 will depend on CSS2.1
22:03:11 [jenyu]
resolution: SVG2 will depend on CSS3 Fonts
22:04:19 [jenyu]
ChrisL: Virtual text and bidi is implemented in some of the plugins that supported SVG but not in many browsers
22:04:51 [sgalineau]
sgalineau has joined #svg
22:05:06 [jenyu]
heycam: text layout should occur according to writing modes and have text positioning and glyph layouts occur afterwards
22:06:38 [jenyu]
resolution: SVG2 will depend on CSS3 writing modes
22:07:23 [jenyu]
resolution: SVG2 will use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG
22:07:51 [sylvaing]
sylvaing has joined #svg
22:07:57 [jenyu]
resolution: SVG2 will depend on CSS3 Color
22:08:42 [jenyu]
ChrisL: Media queries are useful for conditional formatting such as for printing
22:10:41 [jenyu]
heycam: do we want to require support for CSS Animations/Transitions?
22:11:19 [jenyu]
heycam: it's too early to depend on it
22:11:54 [shepazu]
shepazu has joined #svg
22:12:17 [jenyu]
vhardy: maybe we can depend on the result of the results of the FX task force
22:12:22 [jenyu]
resolution: SVG2 will depend on CSS3 Media Queries
22:14:23 [jenyu]
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.
22:14:49 [jenyu]
heycam: we are not going to depend on CSS Transitions/Animations yet.
22:16:20 [jenyu]
shepazu: what's the timeframe for SVG2?
22:17:07 [jenyu]
ChrisL: CSS3 Image Values
22:17:34 [jenyu]
cyril: CSS3 image values as SVG paint servers, we should include it
22:18:22 [jenyu]
sylvaing: CSS3 Image values was split into 2 specs -- CSS3 and CSS4 image values. 3 includes gradient, element,
22:18:44 [jenyu]
resolution: SVG2 will depend on CSS3 Image Values and CSS4 Image Values
22:19:38 [jenyu]
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
22:20:31 [jenyu]
ChrisL: We should adopt the selector and namespace spec for SVG2
22:22:21 [jenyu]
ChrisL: CSS style attribute syntax
22:23:32 [sylvaing]
sylvaing has joined #svg
22:25:44 [jenyu]
jenyu has joined #svg
22:26:23 [sgalineau]
sgalineau has joined #svg
22:26:34 [jenyu]
resolution: SVG2 will depend on CSS style attribute syntax
22:27:10 [ChrisL]
22:27:22 [ChrisL]
"The Text module has been split into three parts: Text, Writing Modes, and Line Grid."
22:27:39 [jenyu]
resolution: SVG2 will depend on CSS3 Selectors and CSS3 Namespaces
22:28:08 [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
22:30:25 [jenyu]
resolution: SVG2 will depend on WOFF
22:30:47 [ChrisL]
draft css charter for next 2 years
22:30:48 [ChrisL]
22:32:11 [jenyu]
resolution: SVG2 will depend on CSS UI and CSS Values and Units
22:34:21 [Zakim]
22:34:24 [Zakim]
- +1.206.675.aaaa
22:34:25 [Zakim]
Team_(svg)21:55Z has ended
22:34:27 [Zakim]
Attendees were +1.206.675.aaaa, ChrisL
22:53:54 [heycam]
ScribeNick: heycam
22:54:01 [heycam]
Topic: Next F2F
22:54:15 [ChrisL]
zakim, code?
22:54:15 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200, ChrisL
22:54:17 [heycam]
Zakim, room for 3?
22:54:18 [Zakim]
ok, heycam; conference Team_(svg)22:54Z scheduled with code 26632 (CONF2) for 60 minutes until 2354Z
22:55:07 [Zakim]
Team_(svg)22:54Z has now started
22:55:16 [Zakim]
22:55:18 [Zakim]
+ +1.206.675.aaaa
22:55:22 [heycam]
Zakim, who is on the call?
22:55:22 [Zakim]
On the phone I see ChrisL, +1.206.675.aaaa
22:57:37 [heycam]
CM: I think we agreed to meet both adjacent to SVG Open and at TPAC
22:57:44 [ed]
22:57:50 [heycam]
CL: I think we agreed to meet for a couple of days before SVG Open
22:57:56 [heycam]
... plus the 2 days at TPAC
22:58:14 [heycam]
... and I think we decided before SVG Open so that we could give status updates at the conference
22:58:39 [cyril]
SVG Open 2011: October 17-20
22:58:53 [cyril]
TPAC 2011: 31 October to 4 November 2011
23:00:25 [heycam]
RRSAgent, pointer?
23:00:25 [RRSAgent]
23:00:56 [heycam]
CC: some people would want to come just for one of the halves of the WG meeting
23:01:03 [heycam]
... or maybe both meetings but not SVG Open
23:01:16 [ChrisL]
23:01:32 [heycam]
CL: the workshops are on the fourth, the thursday
23:02:33 [ChrisL]
s/fourth/fourth day/
23:04:20 [ChrisL]
in my calendar we have thurs and fri as the f2f
23:07:04 [ChrisL]
23:12:24 [heycam]
CC: how about moving the two days of additional F2F meeting time to just before TPAC instead of just after SVG Open
23:14:59 [heycam]
CM: that makes sense to me
23:17:11 [heycam]
CL: have the two days on 27th and 28th (Thursday and Friday)?
23:20:16 [heycam]
CM: ok, let's ask MS to host, and if not perhaps Google can
23:20:57 [heycam]
RESOLUTION: We will meet on 27th and 28th October for the first half of our F2F
23:21:25 [heycam]
Topic: SVG 2 scope
23:21:30 [heycam]
DS: I can see two ways of approaching the problem
23:21:43 [heycam]
... we can either go at it from a schedule perspective, or a feature perspective
23:21:52 [heycam]
... in the former, just see how much we can get done in a certain time
23:22:12 [heycam]
... alternately, we could say these are the features we want to have, we take as long as it needs
23:22:18 [heycam]
CL: I thought we would go somewhere in between
23:22:30 [heycam]
... decide roughly what features we want, see how it goes, drop some features if they are slowing things down
23:22:41 [heycam]
DS: I would kind of like to have a schedule we can work with
23:22:57 [heycam]
CC: you will have to keep to your schedule
23:23:32 [heycam]
... you were talking about 1, 2 or 3 years?
23:23:38 [heycam]
... I don't think 1 year is possible
23:23:57 [heycam]
CL: I think a year is ridiculous unless we're already in CR
23:24:13 [heycam]
... I also don't want to just produce an SVG 1.1 rewritten in new words but has exactly the same features
23:24:42 [heycam]
CC: if we say to the world we are starting on a new version, people may come forward with new features they want
23:24:47 [heycam]
... and we'd have lots of things to deal with
23:24:51 [heycam]
... I agree 1 year is impossible
23:25:17 [heycam]
JY: if you throw out unrealistic numbers ...
23:25:26 [heycam]
CM: so two years until what?
23:25:29 [heycam]
CC: rec?
23:25:47 [heycam]
VH: in software development you set out a date for when you want to do something that seems on the outskirt reasonable, achievable
23:25:56 [heycam]
... and try to lay out a plan to get there, think about your features
23:26:03 [heycam]
... and then you start executing
23:26:22 [heycam]
... when you get through the milestones you adjust your schedule, or you lighten the boat and still make the date
23:26:40 [heycam]
SG: features, quality, ship date. you can have only two.
23:26:48 [heycam]
VH: I think it's good to have a goal
23:27:02 [heycam]
... if you have a schedule like doug is asking, we can have milestones for what we want to achieve
23:27:12 [heycam]
... maybe by the next F2F we can freeze our requirements document
23:27:18 [heycam]
CM: that's a good concrete suggestion
23:27:32 [heycam]
DS: one reason I'm asking is that we got pushback on our charter since we didn't have any dates in there
23:27:53 [heycam]
... they want milestones in terms of "when are you getting to FPWD, LCWD, etc."
23:28:06 [heycam]
... I think there's another way of gauging milestones
23:28:18 [heycam]
... when are we going to have a test suite, complete implementations, etc.
23:28:44 [heycam]
VH: if you take the regular track process, we additionally need a goal for the requirements document in some form
23:28:51 [heycam]
... and then a goal for the test suite
23:28:59 [heycam]
DS: I'd rather have that worked on continuously while we're doing it
23:29:07 [heycam]
VH: so we may set ourselves our own goals
23:29:26 [heycam]
SG: in CSS we have someone who owns the test suite to check for normative statements, etc.
23:29:52 [heycam]
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
23:30:02 [heycam]
... which is a pretty heavy discipline, we didn't end up going for it, but we should consider it
23:30:07 [heycam]
... everyone agrees it's a great idea, right?
23:30:22 [heycam]
... what are the incentives and mechanisms we're going to use to decide if a spec section is mature?
23:30:32 [heycam]
ED: I liked how the CSS test harness listed how many tests there were for a given section
23:30:58 [heycam]
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
23:31:27 [heycam]
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
23:31:30 [heycam]
... that's clearly work as well
23:31:48 [heycam]
... the other part would be integration of new features in the spec and adapting the spec to the new CSS references
23:32:22 [heycam]
... we need one or two editors that integrate new work, changes to references, and people who provide content for the spec
23:32:25 [heycam]
... so we should authors for sections
23:32:32 [heycam]
... and we should have people assigned to work on tests
23:32:42 [heycam]
... for SVG 1.0 we had nearly all the group work on the test suite
23:32:54 [heycam]
... now we have a whole body of tests...
23:33:18 [heycam]
CM: people who are working on new features are probably the best people to write tests for it, though
23:33:26 [heycam]
DS: when I write tests it helps me with the prose writing
23:33:40 [heycam]
VH: if we follow what Sylvain was saying, should we try to organise our work around these roles?
23:34:42 [heycam]
... we have clear milestones for the spec overall -- a first one is just to get the spec building
23:34:49 [heycam]
... and then we can grow that
23:35:18 [heycam]
DS: I think it would be really good if we could demonstrate rather quickly, some time this year, to have a FPWD
23:35:21 [heycam]
... by mid november say
23:35:22 [heycam]
ED: I agree
23:35:48 [heycam]
... it should include some new features by then too
23:35:58 [heycam]
CC: we already have decided on some new things here, like catmull-rom curves
23:36:02 [heycam]
ED: we should highlight these new things
23:36:51 [heycam]
DS: we could have the catmull-rom curves specced out fairly quickly
23:36:55 [heycam]
... we have a script implementation
23:37:28 [heycam]
VH: how do we capture that? on the wiki?
23:37:34 [heycam]
ED: yeah
23:37:36 [heycam]
VH: I will create a page
23:38:21 [heycam]
ED: I think it's a good idea to have at least two people driving each feature
23:38:25 [heycam]
... so they can review each others' work
23:39:00 [heycam]
VH: we should have a "what's new in SVG 2" section in the spec
23:39:47 [heycam]
CL: I'm a bit worried about overpromising
23:39:52 [heycam]
... but I like the idea of testing up front
23:41:22 [heycam]
ED: I think we should have one person at least driving a feature, and one person assigned to be the reviewer of that section
23:41:25 [heycam]
CC: coming back to timeframe
23:41:37 [heycam]
... it's difficult to say when we want to produce a final REC or PR
23:41:43 [heycam]
... but I think we can say what we don't want to do
23:41:47 [heycam]
... five years is too much
23:41:50 [heycam]
... one year is too little
23:42:17 [ChrisL]
23:42:46 [Zakim]
23:43:20 [heycam]
CM: having issued First Last Call WD by two years?
23:43:27 [ChrisL]
23:44:23 [heycam]
VH: I think we should have feature list settled by TPAC
23:44:34 [heycam]
... like gradient meshes, path improvements, etc. and say that's closed
23:44:49 [heycam]
DS: also we have to worry about how long implementations will take to catch up
23:45:36 [heycam]
... we definitely need new features, but once we have the momentum going we can always add more
23:45:43 [heycam]
CC: do you plan to have a "call for features"?
23:46:07 [heycam]
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
23:47:26 [sylvaing]
sylvaing has joined #svg
23:49:29 [heycam]
VH: let's have a proposed requirements document to bring in to TPAC
23:49:38 [heycam]
... and to resolve on it at that meeting
23:49:55 [heycam]
DS: we should have use cases for them, too
23:50:13 [heycam]
VH: they should be in that document
23:50:28 [heycam]
CC: and examples of existing technologies doing it
23:52:32 [heycam]
VH: I will add some proposed milestone dates to the wiki page and we can discuss that on a telcon soon
23:53:12 [heycam]
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
23:53:20 [heycam]
... we've had a lot of people ask for this
23:53:24 [heycam]
SG: that's a source of use cases there
23:53:32 [cyril]
s/existing technlogies/existing technologies (proprietary or not)/
23:55:52 [heycam]
CC: we should look at SVG Tiny 1.2 to see what features there we want to bring forward
23:57:48 [heycam]
ACTION: Cyril to look at SVG Tiny 1.2 and come up with a list of major features that aren't in 1.1
23:57:48 [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].
23:59:01 [Zakim]
disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)22:54Z
23:59:06 [Zakim]
Team_(svg)22:54Z has ended
23:59:07 [Zakim]
Attendees were ChrisL, +1.206.675.aaaa
23:59:32 [heycam]
00:00:42 [heycam]
VH: somebody should own the requirements document
00:00:57 [shepazu_]
shepazu_ has joined #svg
00:01:10 [heycam]
00:13:43 [heycam]
Topic: Media resources spec review
00:13:48 [heycam]
ED: I posted some comments to our list for review
00:16:03 [ed]
00:16:06 [cyril]
00:16:38 [ed]
00:20:04 [heycam]
ACTION: Cyril to respond with comments on the API for Media Resources 1.0 spec
00:20:04 [trackbot]
Created ACTION-3101 - Respond with comments on the API for Media Resources 1.0 spec [on Cyril Concolato - due 2011-08-06].
00:27:04 [heycam]
Topic: sharing path segments
00:27:09 [heycam]
CC: if you look at this wiki page
00:28:29 [heycam]
00:28:51 [heycam]
... the shared/reverse path link is an SVG Open presentation my colleague presented last year
00:28:55 [heycam]
... one use case is maps, the other is comics
00:29:03 [heycam]
... in those kinds of content, you re-use many paths
00:29:08 [heycam]
... sometimes you use them as a border of two regions
00:29:25 [heycam]
... sometimes when you mkae holes in a shape, by overlapping another shape on top of it, you may have shared borders there
00:29:35 [heycam]
... he tried to work on solutions to reuse this path
00:29:54 [heycam]
... if you look at slide 16 he proposed a syntax using superpath and subpath
00:30:04 [heycam]
... he discovered vePath and vePathRef in SVG 1.2 Full
00:30:22 [cabanier]
cabanier has joined #svg
00:30:30 [heycam]
... 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
00:31:00 [heycam]
... it's important for animation, file size reduction, doing adaptation like LoD with consistent degredation of paths
00:31:13 [heycam]
... so we think it's important to be in SVG 2
00:31:20 [heycam]
... don't care if it's vePath or superpath
00:31:38 [heycam]
DS: this seems very closely linked to the idea of the extended path syntax where it expands out into elements
00:31:42 [heycam]
CC: the canon proposal?
00:31:45 [heycam]
DS: the one used for EXI
00:31:52 [heycam]
... instead of a compact syntax...
00:31:55 [heycam]
CC: it's a different thing
00:32:02 [heycam]
... compact vs non-compact has dom implications
00:32:08 [heycam]
... I just want to talk about requirements first
00:32:21 [heycam]
... do you agree it would be nice?
00:32:23 [heycam]
DS: yes
00:32:25 [heycam]
CM: yes
00:32:30 [heycam]
CC: then syntax discussion
00:32:52 [heycam]
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?
00:33:24 [heycam]
... you could have only inner strokes and then the countries edges would not overlap
00:40:32 [heycam]
ACTION: Cyril to write up proposal page for path shared edges
00:40:32 [trackbot]
Created ACTION-3102 - Write up proposal page for path shared edges [on Cyril Concolato - due 2011-08-06].
00:41:27 [heycam]
Topic: polar element
00:41:36 [heycam]
DS: there were some discussions, Dr O made a proposal
00:42:20 [shepazu]
00:43:07 [heycam]
... we never ended up having a regular polygon/star shape
00:43:25 [heycam]
... you can do them, but it's not trivial
00:43:42 [heycam]
... it would be good for dynamic updates to have a geometric star shape than a path you have to change the geometry of
00:45:26 [ed]
00:46:52 [heycam]
... Olaf's page can do more complex things than mine
00:47:05 [heycam]
CC: why does it need to be declarative? for animations?
00:47:33 [heycam]
DS: you can do it in JS, but sometimes I just want to say "I want a hexagon that fits in this box"
00:49:35 [heycam]
CM: with the path rotation command it becomes reasonably easier to do regular polygons
00:49:37 [heycam]
... stars too
00:49:49 [heycam]
CC: so we agree on the use case
00:50:01 [heycam]
... we have these three ways we can do it, your polar, olaf's polar, path rotation command
00:50:33 [heycam]
DS: spirals is another one
00:54:54 [heycam]
ACTION: Doug to make a wiki proposal page for polar/star/polygon/path extensions
00:54:55 [trackbot]
Created ACTION-3103 - Make a wiki proposal page for polar/star/polygon/path extensions [on Doug Schepers - due 2011-08-06].
00:55:49 [vhardy]
00:59:35 [Zakim]
Zakim has left #svg
01:03:47 [heycam]
01:04:02 [heycam]
RRSAgent, make minutes
01:04:02 [RRSAgent]
I have made the request to generate heycam