- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 29 Jul 2011 22:38:02 -0700
- To: www-svg@w3.org
http://www.w3.org/2011/07/29-svg-minutes.html and below as text. Note
that again the minute taking bot has become confused, so the HTML
version linked above has both
Present were: Cameron McCormack, Erik Dahlström, Vincent Hardy, Rik
Cabanier, Doug Schepers, Jennifer Yu, Cyril Concolato, Sylvain Galineau,
Tab Atkins Jr., Chris Lilley (phone), Tavmjong Bah (phone)
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
29 Jul 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/07/29-svg-irc
Attendees
Present
ChrisL, +1.206.675.aaaa
Regrets
Chair
SV_MEETING_CHAIR
Scribe
TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
Contents
* [3]Topics
1. [4]SVG Color
2. [5]SVG Vector Effects
3. [6]SVG Compositing
4. [7]Advanced Gradients
5. [8]current gradient issues.
6. [9]fr attribute on radialGradients
7. [10]Compositing
8. [11]css dependencies
9. [12]Next F2F
10. [13]SVG 2 scope
11. [14]Media resources spec review
12. [15]sharing path segments
13. [16]polar element
* [17]Summary of Action Items
_________________________________________________________
<trackbot> Date: 29 July 2011
<ChrisL> Meeting: SVG f2f Seattle
<TabAtkins_> ScribeNick: TabAtkins_
SVG Color
ChrisL: Some links to start.
<ChrisL>
[18]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Color#Tagged_im
ages
[18]
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>
[19]http://dev.w3.org/SVG/modules/color/master/SVGColor.html
[19] http://dev.w3.org/SVG/modules/color/master/SVGColor.html
ChrisL: That's the actual spec.
<ChrisL>
[20]http://dev.w3.org/cvsweb/~checkout~/SVG/modules/color/master/col
or-notes.txt?rev=1.2;content-type=text%2Fplain
[20]
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> [21]http://www.w3.org/TR/SVG/feature.html
[21] http://www.w3.org/TR/SVG/feature.html
<shepazu> could be
[22]http://www.w3.org/TR/SVG11/feature#textPath.method.stretch
[22] 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>
[23]http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection
[23] 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>
[24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements (see
test section)
[24] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
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>
[25]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects
[25] 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>
[26]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffe
ctsPrimer.html
[26]
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>
[27]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffe
cts.html
[27]
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
[28]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 [29]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>
[30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects
[30] 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
<br duration=15min>
<tbah> OK, I'll call in anyway. The girls are in bed. Peace has
returned.
<vhardy> ScribeNick: vhardy
SVG Compositing
Advanced Gradients
<tbah> [31]http://tavmjong.free.fr/SVG/MESH/Mesh_Inkscape.html
[31] 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_> [32]http://www.xanthir.com/etc/text-stroke-start.html
[32] 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> [33]http://tavmjong.free.fr/SVG/MESH/Mesh.html
[33] 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 <!-- New row --> 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
[34]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>
[35]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/G
radients
[35]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Gradients
<tbah> zakim +39.537 is me
[36]http://apike.ca/media/svg/exampleRadGradFP.svg
[36] http://apike.ca/media/svg/exampleRadGradFP.svg
<cyril_>
[37]http://perso.telecom-paristech.fr/~concolat/exampleRadGradFP.svg
[37] http://perso.telecom-paristech.fr/~concolat/exampleRadGradFP.svg
ed: this behaves differently in all browsers
<ed> <radialGradient id="myRadGrad" fx="80%" r="10%"
spreadMethod="reflect" >
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> [38]http://www.w3.org/TR/SVG11/pservers.html#RadialGradients
[38] 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
[39]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
[40]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_> [41]http://www.w3.org/TR/SVGCompositing/
[41] 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:
[42]http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/de
vnet/pdf/pdfs/PDF32000_2008.pdf
[42]
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
[43]http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/de
vnet/pdf/pdfs/PDF32000_2008.pdf
[43]
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> [44]http://www.w3.org/TR/SVG/filters.html#feBlendElement
[44] 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>
[45]http://www.w3.org/TR/SVGCompositing/#containerElementBackgoundCo
ntrol
[45]
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
[46]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
[47]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>
[48]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/C
SSDependencies
[48]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/CSSDependencies
css dependencies
<ChrisL>
[49]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/C
SSDependencies
[49]
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> [50]http://www.w3.org/Style/CSS/specs#text
[50] 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>
[51]http://www.w3.org/2010/09/CSSWG/charter.html#deliverables
[51] 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> [52]http://www.w3.org/2011/11/TPAC/
[52] 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>
[53]http://www.svgopen.org/2011/registration.php?section=conference_
schedule
[53]
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> [54]http://www.w3.org/2011/11/TPAC/#Finalized
[54] 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
[55]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].
[56]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals
[56] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals
VH: somebody should own the requirements document
[57]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals
[57] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals
Media resources spec review
ED: I posted some comments to our list for review
<ed>
[58]http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/002
5.html
[58]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0025.html
<cyril> [59]http://www.w3.org/TR/mediaont-api-1.0/
[59] http://www.w3.org/TR/mediaont-api-1.0/
<ed>
[60]http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/002
4.html
[60]
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
[61]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
[62]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
[62] 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
[63]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> [64]http://svg-whiz.com/svg/StarMaker.svg
[64] 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> [65]http://hoffmann.bplaced.net/svgueb/polar.php
[65] 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
[66]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>
[67]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page#Test_S
uite_Requirements
[67]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page#Test_Suite_Requirements
vhardy, [68]http://www.w3.org/Graphics/SVG/WG/track/actions/3045
[68] http://www.w3.org/Graphics/SVG/WG/track/actions/3045
Summary of Action Items
[NEW] ACTION: cabanier to Give a description of how porter-duff
behaves differently from blend modes (group invariance) [recorded in
[69]http://www.w3.org/2011/07/29-svg-minutes.html#action07]
[NEW] ACTION: ChrisL to write up spec text for currentFillPaint,
etc. [recorded in
[70]http://www.w3.org/2011/07/29-svg-minutes.html#action01]
[NEW] 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
[71]http://www.w3.org/2011/07/29-svg-minutes.html#action08]
[NEW] ACTION: Cyril to respond with comments on the API for Media
Resources 1.0 spec [recorded in
[72]http://www.w3.org/2011/07/29-svg-minutes.html#action09]
[NEW] ACTION: Cyril to write up proposal page for path shared edges
[recorded in
[73]http://www.w3.org/2011/07/29-svg-minutes.html#action10]
[NEW] ACTION: Doug to make a wiki proposal page for
polar/star/polygon/path extensions [recorded in
[74]http://www.w3.org/2011/07/29-svg-minutes.html#action11]
[NEW] 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 [75]http://www.w3.org/2011/07/29-svg-minutes.html#action02]
[NEW] 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
[76]http://www.w3.org/2011/07/29-svg-minutes.html#action04]
[NEW] ACTION: ed to provide spec. wording for the fr attribute on
<radialGradient> [recorded in
[77]http://www.w3.org/2011/07/29-svg-minutes.html#action05]
[NEW] ACTION: Give a description of how porter-duff behaves
differently from blend modes (group invariance) [recorded in
[78]http://www.w3.org/2011/07/29-svg-minutes.html#action06]
[NEW] ACTION: tbah to update the coon's mesh proposal to make it
both a geometric primitive and a paint server. [recorded in
[79]http://www.w3.org/2011/07/29-svg-minutes.html#action03]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [80]scribe.perl version 1.136
([81]CVS log)
$Date: 2011/07/30 01:04:08 $
_________________________________________________________
[80] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[81] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [82]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[82] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/icc/cmyk/
Succeeded: s/sbasic/sbasis/
Succeeded: s/test/mesh/
Succeeded: s/yes/no/
Succeeded: s/tab/tav/
Succeeded: s/case/cases/
FAILED: s/<def>/<defs>/
FAILED: s/gradial/radial/
FAILED: s/the average/the weighted (by offset) average/
FAILED: s/fourth/fourth day/
FAILED: s/existing technlogies/existing technologies (proprietary or no
t)/
Found ScribeNick: TabAtkins_
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
WARNING: No scribe lines found matching ScribeNick pattern: <TabAtkins_
> ...
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
WARNING: No scribe lines found matching ScribeNick pattern: <TabAtkins_
> ...
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
Found ScribeNick: heycam
Found ScribeNick: TabAtkin1_
Found ScribeNick: vhardy
Found ScribeNick: jenyu
Found ScribeNick: heycam
Inferring Scribes: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
Scribes: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
ScribeNicks: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa tbah ChrisL +39.537.7.aabb
New list: +1.206.675.aaaa ChrisL
Default Present: ChrisL, +1.206.675.aaaa
Present: ChrisL +1.206.675.aaaa
WARNING: Fewer than 3 people found for Present list!
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 29 Jul 2011
Guessing minutes URL: [83]http://www.w3.org/2011/07/29-svg-minutes.html
People with action items: cabanier chrisl cyril doug ed give tbah
[83] http://www.w3.org/2011/07/29-svg-minutes.html
End of [84]scribe.perl diagnostic output]
[84] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Saturday, 30 July 2011 05:38:51 UTC