See also: IRC log
<heycam> ... there was a level of zoom requirement item too
<heycam> ... just put an attribute for minimum/maximum zoom level on any element
<heycam> CM: the Tiling/Layering will be a separate document, right?
<heycam> CL: that won't allow you to do the complex/simpler path kind of level of detail though
<heycam> [discussion of differences between tiling, LoD, auto fetch/discard]
<heycam> RESOLUTION: We won't include automatic fetch/discard in SVG2.
<heycam> CM: this one sounds more interesting to me
<heycam> RESOLUTION: We will support Level of Detail control in SVG2.
<heycam> CC: now the one we should go back to is templating for controls and widgets
<ed> ED: already resolved earlier this morning
<heycam> ED: next, transform on svg elements
<heycam> CL: what does that help with?
<heycam> ED: nested svg elements
<heycam> CM: seemed odd to me not to allow transform on svg
<heycam> ... but it might be confusing for authors wrt order of application of transform and viewBox
<heycam> RESOLUTION: We will allow transform on <svg> in SVG2.
<heycam> ED: next, allowReorder on switch
<heycam> CL: this came out of a request from mozilla that switch with requireLanguage is less useful when you have a list of ordered preferred user languages
<heycam> ... it got added in SMIL3
<heycam> CM: it has a bad name
<heycam> RESOLUTION: We will support a mechanism like or the same as allowReorder from SMIL3 in SVG2.
<heycam> ED: next, allow referencing root external files with use
<heycam> DH: with <use>, you get the same animation timeline, vs if you use image
<heycam> CM: also with events you can distinguish which shadow tree elements was clicked, for example
<heycam> DH: would this apply to other things that reference external elements, like mask?
<heycam> ED: maybe wouldn't make sense there
<heycam> CC: there is the animation element in 1.2T, is that relevant here?
<heycam> ED: but that only references a whole document anyway
<heycam> CL: in 1.2T we split it up into <image> for more static images, and <animation> for animated ones
<heycam> ... with <animation> you can use the SMIL timing attribtues on it, so you can control its timeline separately
<heycam> ... but you can't do that with animated SVG referenced from <image>
<heycam> ... the name animation is confusing though, compared to animate
<heycam> ... in the end though image was able to point to svg content
<heycam> ... so we may or may not want to keep <animation>, possibly renamed
<heycam> RESOLUTION: We will relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use, in SVG2.
<heycam> ACTION: Cyril to investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action01]
<trackbot> Created ACTION-3157 - Investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [on Cyril Concolato - due 2011-11-04].
<heycam> ED: next, in the Attributes section, is Parameters
<heycam> CC: we need this
<heycam> DS: we decided last time that we would not make this general
<heycam> CC: in what sense?
<heycam> DS: in the sense that this would not be a CSS thing, it's an SVG thing
<heycam> ... although people are going to want to pass things in to CSS
<heycam> ... in CSS embedded in SVG, you would want a legal value to be a param
<heycam> ... I think we thought it would take too long to get into CSS as well
<heycam> ... but having it attribute only would have this downside
<heycam> ... especially if people are using SVG and CSS together more
<heycam> CM: I would really like to see if we can use CSS Variable as the in-CSS way to reference parameters
<heycam> DS: maybe we should move ahead with it as a separate spec
<heycam> CL: Tab is in general happy to add new values to CSS Values
<heycam> DS: it's effectively like calc, in terms of scope
<heycam> ... I see param working with calc really well
<heycam> CC: do we want to allow params to work with presentation attributes, style properties, geometry attributes, SMIL attributes...?
<heycam> DS: I want it to apply to every SVG attribtue, and maybe property values as well
<heycam> CC: how about using them in script?
<heycam> DS: there's the DOM interface that exposes params and their values
<heycam> ... anything I do with params I would like to decompose a shorthand for Component Model
<heycam> [discuss some details of Params]
<heycam> DH: I would be a bit concerned about being gated on CSS work
<heycam> DS: we could say that for now, it works only in attributes, but that we're open to the CSS WG allowing this in property values
<heycam> ... and I'd expect there'd be experimental implementations to see if there are any issues with allowing that
<heycam> CL: we did already talk about this within FX
<heycam> RESOLUTION: We will have Parameters in SVG2, worked on in a normatively referenced separate spec.
<ChrisL> Meeting; SVG WG f2f Mountain View
<heycam> shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/
1075 La Avenida
Mountain View, CA 94043
Tel: (650) 693-1005
<trackbot> Date: 28 October 2011
<heycam> Meeting: SVG Working Group Mountain View F2F 2011, day 2
<heycam> Chair: Cameron
<ChrisL> Scribenick: ChrisL
heycam: this is to align with
... confusing to not be abletodio this in mixed html5/svg
resolution: we willadd data-* attributes in SVG2 to align with HTML5
ed: this could be done in script
cc: there is not much of a proposal here
resolution: we will not add declarative randomisation functionality in SVG2
<trackbot> ISSUE-2048 -- Consider adding certain HTML attributes used in microformats -- raised
ChrisL: ARIA isalso somethig that should be supported - related
heycam: higher level goal is to
bring across globalattributes thatmake sense, ratherthan
... consider together with aria
resolution: we will align with HTML5 globalsemantic attributes wherethese make sense for SVG
<scribe> ACTION: ChrisL to look at global attributes [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action02]
<trackbot> Created ACTION-3158 - Look at global attributes [on Chris Lilley - due 2011-11-04].
heycam: there were complaints about this at svgopen
vhardy: the complaint was
actually attribute and element names being case sensitive
... we could deprecate oneset of names and introduce new ones
ChrisL: makes more confusion than it helps
vhardy: example is textPath, cant search for getElementbyTagName
ChrisL: so it does work as long as you spell it consistently
heycam: tested just now, it recognises the statndard spelling but does not recognised the fixed-up name
<heycam> If you have `<!DOCTYPE html>...<textpath ...>` then you do document.getElementsByTagName("textpath"), it won't find the element
<heycam> but if you do ...getElementsByTagName("textPath") it will
<heycam> If you have `<!DOCTYPE html>...<textPath ...>` and you do document.getElementsByTagName("textPath"), it will find it
ChrisL: it only fixes up when parsing, not in script
heycam: wonder about adding magic to getElementsByTagName
cyril: two issues,values and element/attribute names.
heycam: any objections to making property values as attributes case insensitive?
cyril: IDs are case sensitive
erik: all presentation attributes are safe to do this with
resolution: make property values case insensitive
ChrisL: so in the dom the case is preserved?
ChrisL: sad that the dom is still
required to preserve whatever case combination was used each
time, in case you ask for it back
... could this be normalised like we did in udom?
(chris talks at lemngth and forgets to minute)
<scribe> ACTION: chris to reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action03]
<trackbot> Created ACTION-3159 - Reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [on Chris Lilley - due 2011-11-04].
ChrisL: have several offers of reviews for this. would like to publish, get the review, then go to w3c last call
heycam: should this be normatively required by SVG2
this is something operating systems all do not (but not onmobile)
cyril: name is confusing can we
rename to color-management
... intro shouldsay it is a supersetof SVG color chapter and of CSS3 color
ChrisL: yes it should state that explicitly
ed: what t do with css3 images
and css gradients as they affect paint?
... ok with the conformance class that does color managed images
heycam: we can have several conformance clasees in this spec then decide later which ones svg2 requires
ChrisL: happy with that
resolution: svg2 will depend on svg colormanagement subject to deciding the exact conformance classes required
ChrisL: this could be a separte
module or it could be a chapter, its written as a drop-in
... makes more sense to have this as the color chapter in fact
resolution: svg colormanagement becomes a chapter in SVG2
<scribe> ACTION: ChrisL to edit the svg colormanagemtn spec into a chapter in SVG2 [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action04]
<trackbot> Created ACTION-3160 - Edit the svg colormanagemtn spec into a chapter in SVG2 [on Chris Lilley - due 2011-11-04].
<scribe> scribenick: dholbert
CM: lots of people want this, and it's not too hard to implement
<tbah> Hi, phone?
resolution: svg2 will include non-scaling stroke
<ChrisL> tbah: inkscape has non scalingstroke and non scalling patterns
ED: maybe things in general that are non-scaling could go into another coordinate system
CM: might be interesting to look into other things that you might want to not scale
CC: e.g. rectangle with radius=5
on the corner, you might want to grow the rectangle but not
grow the radius of the corner
... there's also non-scaling whole objects, e.g. legends in a map
CL: doesn't tiny 1.2 let you do something like that, by saying "this part is in the coordinate system over there"?
CC: we also have the transformBehavior attribute, for video
CC: it has the value 'pinned' which would help with this as well
ED: it'd be nice to hear more about the non-scaling things in inkscape
CL: non-scaling patterns (inkscape option) sounds interesting
CM: perhaps tav can write up a summary of inkscape's non-scaling features
<scribe> ACTION: tav to write up summary of inkscape's non-scaling features, as possible candidates for svg2 [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action05]
<trackbot> Created ACTION-3161 - Write up summary of inkscape's non-scaling features, as possible candidates for svg2 [on Tavmjong Bah - due 2011-11-04].
resolution: svg2 should include non-scaling features, aside from non-scaling stroke. (2 separate components: non-scaling part of the object, and non-scaling entire object)
CL: we're lacking a fully
fleshed-out proposal for this
... we don't want to be forced to put stroke-width "stops" only at the nodes
... more like a gradient, with stops that can be specified
... and each stop has a stroke-width specified
VH: how do you author variable stroke-width in inkscape?
TB: there are 2 ways. the one in
... you draw a path, and then a second path the "skeleton", and the first path is warped along the skeleton
... one path describes the width, and that gets put along the other path.
... e.g. you could draw a lizard, and bend the lizard along the path
... so that's the first method. the second method is: you add nodes along the path, and manipulate those (like what CL described with "stops")
VH: warping is interesting, since we need to do that for text anyway
CL: but the "stops" way is more natural for e.g. drawing with a pressure-sensitive pen
resolution: svg2 shall include variable stroke-width
ED: I think this is roughly the same as stroke-position
CM: This is something many people want to be able to do
resolved: svg2 shall include a way to specify stroke-position
resolution: svg2 shall include a way to specify stroke-position
CM: what isn't defined at the moment?
CL: the start point of the
dashing on basic shapes like circles
... and on multi-segment paths, e.g. if you're partway through a dash at the end of one segment, do you start the next segment with just a partial dash
resolution: svg2 shall specify stroke dashing more precisely
CM, to be able to do things like align dashes exactly on corner of a rectangle
resolution: svg2 shall allow more author control over positions of dashes
TB: Couple problems with trying
to use patterns for this. one is, if you use a diagonal line,
you'll often get misalignments
... also, SVG is used for e.g. engravers, who want to be able to do one continuous stroke across a background.
CL: same applies to plotters
CM: not sure if this would have a predefined set of hatches, or let you define your own
CC: could be useful for cartoons
ED: though in that case you could probably just use a pattern
<ChrisL> Hatching (hachure in French) is an artistic technique used to create tonal or shading effects by drawing (or painting or scribing) closely spaced parallel lines
VH: I've encountered the issue with patterns. the main convincing argument to me is TB/CL's points about one needing continuous lines for certain use-cases
CM: It seems like something worth looking into
resolution: svg2 should support hatching without the artifacts that patterns currently impose
<ChrisL> http://fr.wikipedia.org/wiki/Hachure has more detail actually
CM: sounds like we've got this already solved by CSS image-values
CL: seems like this could be simpler than that though, just expanding the types of things that are allowed as paint servers
CC: would we need to specify preserveAspectRatio=meet|slice?
JY: would we need the background-* properties? e.g. background-position, background-size
CM: SVG doesn't really know about background images at the moment
CL: but we could model the behavior off of that, perhaps
resolution: svg2 shall support filling and stroking from arbitrary elements
ED: I think it's covered by CSS shaders, depending on the outcome of the discussion there
CM: there's a question of whether that's a hard dependency
CL: the ability to write custom shaders is pretty important
resolution: svg2 shall support custom filters (shaders)
CM: I wouldn't like to be
different from HTML's syntax for this
... and note that you can already @import from inside of style
<ChrisL> ISSUE-2049: this would diverge ftom HTML, better to add the link element. Can also do @import
<trackbot> ISSUE-2049 Consider adding an href to the style element to link to external stylesheets notes added
JY: perhaps this is wanting to bring in the <link> element? (that's what is used for this in HTML)
resolution: svg2 shall not add href to the <style> element
CM: this is e.g. 'media' and 'scoped' attributes
resolution: svg2's style element shall be aligned with the html5 style element
CC: jasper proposed nonlinear transforms; that's what vertex shaders are about
VH: you actually deform a texture; you're not deforming the geometry itself
<tbah> Conference timed out, could you restart?
CC: jasper wanted to separate the
gradient map from the transformation map
... the transformation map could be used for text warping or object warping
... I think it's very similar to vertex shaders; you have an initial object, you give the end object, and you interpolate in between
CM: If we have vertex shaders, do we need this?
CL: Shaders are about transforming the rendered result; this is about transforming the geometry
VH: For example, if you're transforming a straight line into a curve, a vertex shader would transform it into small line segments - not actually transform the geometry
CM: we're already getting perspective transforms from CSS3 transforms, right?
VH: yes, but that's transforming
the rendered output, not the geometry
... in SVG, with geometry transforms, we think about it transforming the bounding box. With a warp filter, you wouldn't get the bounding box from the resulting rendered output
TB: How do you define these transforms?
CM: That's an open question
TB: mathematical equations?
CC: or you provide a grid
... I'm concerned in terms of authoring, that you'd end up with lots of shaders, lots of GLSL - not really declarative.
... it should be possible to specify a transformation without writing a shader
CM: In some ways I'd like to be able to do fancy warping, but it seems like a really open-ended/big feature
CL: mercator was one of the
suggested transformations; if we were to make a fixed list of
allowed transformations, someone's always going to want a
... so it'd need to be customizable
... so I have concerns over complexity & extensibility
CM: we also haven't seen people
using script to do these kinds of effects
... but with a nicer API, we might see people doing more of this
ED: that example I just pasted is a 3D projection of a world map, so people are doing that kind of thing
(demo of spinning globe, with SVG countries painted onto it)
CC: It'd be really cool to be able to animate a globe like this with declarative animation, without needing any script
CM: to be happy moving forward with something, I'd want some kind of proposal & people really championing it / wanting to implement it
resolution: svg2 shall not include alternative transforms, in the absence of a convincing proposal
CM: <replicate> is listed
here, but that belongs under 'declarative drawing'
... and the other things fall under the previous topic
... and in fact the next one as well ('non-rectilinear layout models') -- that sounds like arbitrary warping transforms as well.
... that sound like the same use-case as like the mesh transforms
CL: I think we went over this in
the 1.1 timeframe; we decided not to put it in 1.1 but we
thought we'd put it in 2
... we definitely decided to add it, and it's been asked for since
... [expresses displeasure for markers]
resolution: svg2 shall include better bounding-box querying functions
TB: this is a good idea; you also need to be able to specify the center of rotation
CL: We get this for free in the CSS transforms
CM: hopefully all the CSS properties we support will have presentational attributes, too
CC: So in CSS, this is the "transform-origin" property?
CL: yes. CSS defaults to rotating about the center, whereas SVG defaults to rotating about upper-left corner
TB: how do you get the center of e.g. a rotating 5-pointed star, where the bounding box changes as it rotates?
VH: the center of rotation would be chosen pre-transform
resolution: we will ensure there is a way to specify rotations around particular points and shapes
TB: Inkscape stores a
transformation center; used for scaling, for skewing
... not just for rotations
VH: something similar in illustrator, too
<ed> scribeNick: ed
CL: geometry api?
CM: vincent wanted to talk about
... maybe we can have that discussion later
<trackbot> ACTION-1 does not exist
<trackbot> ACTION-100 does not exist
CM: we were discussing having better interfaces for points, paths, and combining and offsetting
CL: the other one was
... assuming this ends up as a vector-effect value
DS: i suspect that CSS ppl are going to think it's like an underline
CL: fill then stroke then markers
DS: what if it's the middle thing?
CL: markers, fill, then stroke?
DS: it's not the full functionality, it's a shorthand
CC: what if you wanted to have
both non-scaling-stroke AND stroke-below-fill?
... what's the philosophy behind the vector-effects property?
CL: it's like a filter
... I could do add combination value keyword
CM: concerned about using vector-effect for this
CL: most things in filter effects are called 'feSomething', and in vector effects 'veSomething'
DS: is the property vector-effect
appropriate and intuitive to what ppl would expect?
... what if you wanted the fill on top of the stroke for text in html?
... do we have the same mechanism for that?
CM: so you want a slightly
differnt way to express this, rihgt?
... mapping the "i want stroke under the fill" to using "vector-effects" perhaps is not so intuitive
... though having them separate might make it harder for linking it to vector-effects
... we have existing stroke and fill, and that's input to the vector effects
CL: plus the styling
<ChrisL> stroke-order: above-fill (default) | below-fill
CM: it's not the order that's below the fill
DS: maybe we could have a poll to what's most intuitive?
CM: but maybe we could resolve on separating the property out, not making it a vector-efffect shorthand
<ChrisL> paint-order: fill-stroke-marker| stroke-fill-marker | and so on
RESOLUTION: we will have a property that means stroke underneath fill vector-effect shorthand, but not using the vector-effect property
CL: do we want to use vector-effects=non-scaling-stroke as is, or separate it out?
DS: could be a threshold, scale up as much as it can go, but min value is 1
CM: would like to see this as a separate property for non-scaling-stroke
DS: helps discoverability
ED: so vector-effects would only be the url() syntax?
CM: if we don't come up with something else that we can use as shorthands
ED: slight concern about
backwards compat, since it's implemented as a vector-effect
... also non-scaling-stroke="yes|no"? seems a bit silly
... and all other stroke properties are prefixed 'stroke-'
DS: to me it's a vector-effect,
underneath it's the same thing
... doesn't need to be called vector effect...
CM: it's not terrible in
vector-effects, but i'd prefer it as a separate attribute
... the painting order is a simple thing compared to the vector effects
RESOLUTION: we will keep vector-effect=non-scaling-stroke as is
<stakagi> Initially, I thought that ref (svg, x, y) made it satisfied for non-scaling-whole-objects.
<stakagi> But, another fixed-size-shapes may be required.
<stakagi> Differ from the ref(svg,x,y), for map usecase totally fixed-size-shape are required, such as line-width of vector effects. By ref(svg,x,y), shape size is fixed but initial size is not fixed according to ( SVG user agent viewport and viewBox))
<heycam> stakagi, I think the performance concern's true, as long as the appropraite coordinate space is the root element
CL: yes, we mentioned ref before, it's on the requirements list right?
<stakagi> This matter is pointed by Alex
CM: so you want to get around the outermost svg scaling and get a fixed pixel size for the scaling to screen
CM: thinking about viewBox, lack
of viewBox, and how wide things are in screen pixels
... just sizing the viewport to the size of the window
DS: things that are meant to be a
fixed size could be optimized, render to that size and then
... like buffered-rendering
CM: right, like how "position:
absolute" in css means it's usually a hardware layer
... we can leave the details of the mapping and layering until next week at TPAC
CM: first, stroke-position,
proposed by Jeremie
... we already resolved to include the feature in SVG2
CC: what's the lneght valiue?
CM: positive means outwards, negative inwards
[CL draws stroke on whiteboard]
CM: length is in user units
CC: it doesn't say what the range of the length, where is e.g 1, 0 and -1
CL: you could have a percentage
which is relative to stroke-width
... or an absolute value in user units
CM: there are some image attachments on the page above, showing different scenarios
DS: i can imagine having a stroke
around and then wanting a second stroke
... multiple strokes could be very useful
CM: that's possible with vector effects
DS: the figleaf example is
... if there was a way to fill the space beween the fill and the stroke
CC: so what is the conclusion?
DS: i'm in favor of this proposal
CM: we should put it in draft
CC: some drawing APIs don't have the capability to do this I think
CM: is it too much to ask?
DS: in the 0062.html mail, the third image seems intuitive, and the figleaf is intuitive... the first one though, how do you get that?
[CC draws on whiteboard]
<heycam> Path flattening/offsetting algorithm: http://www.google.com/url?sa=t&rct=j&q=%22fast%20precise%20flattening%20of%22&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.106.5344%26rep%3Drep1%26type%3Dpdf&ei=ZyOrTsIsiJiIApDevLML&usg=AFQjCNFc8ypX4PbNIvPWtcd-Wg7yrHWxDg&sig2=lu_5yuGGUnHREOhkSlPOgg&cad=rja
DS: do we need something like stroke-rule, similar to fill-rule?
CC: what happens with
... are the definitions we have capable of handling these new functionality when strokes are outside or inside?
... it's probably not so easy to define what's inside and outside
CM: we already know for a path
what the stroke will be
... so to get the new stroke just offset the stroke more or less than is currently done with stroke middle
... the paper just looks at left and right sides of a stroke, for determining what parts should disappear when the stroke folds over itself
CC: let's say you want to animate the stroke-distance
[CC draws a star, with a hole in the middle]
scribe: i think it uses
... you don't use even-odd when you're filling the strokepath
... but we're talking about different things, the stroke isn't the fill
CM: in the end what you get from
a stroking operation is a normal path that you can fill
... might be interesting to experiment with implementing
... for the syntax of the proposal, no specific suggestions for improvments?
DS: we should play with it and see how well it works
CL: paper addresses performance of this, and it's just as good as any other stroking operation
CM: are you likely to get seams
if you offset from the fill?
... that is, the space between the fill and the stroke, if you have stroke-position=outside
DS: think people would like this situation to produce no seams
CC: should we also have a more
general shape-offset that offsets the shape geometry by a
... i think that's a vector effect
CM: yes, I think this might be a less common operation, so that's probably fine
CL: you do get a problem if the
tesselation is dfifferent for the stroke and the fill
... some pixles may end up with less coverage and the background might bleed through
<scribe> ACTION: CM to put the stroke-position proposal into the SVG2 spec [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action06]
<trackbot> Sorry, amibiguous username (more than one match) - CM
<trackbot> Try using a different identifier, such as family name or username (eg. charles, cmccorma)
<scribe> ACTION: cameron to put the stroke-position proposal into the SVG2 spec [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action07]
<trackbot> Created ACTION-3162 - Put the stroke-position proposal into the SVG2 spec [on Cameron McCormack - due 2011-11-04].
CM: i wrote this proposal to address adaptive stroke-dashing
[CM draws on whiteboard]
CM: to adjust the dashes to e.g get a dash at the start and the end of a path, and then space the rest out along the curve
CL: another case is for rectangles, where you want the corners to have dashes
CC: if you have percentages for stroke-dasharray / dashoffset maybe it would address some part of this
CM: either stretch the gaps, or stretch the dashes, or both
CC: or compress
CM: maybe what this proposes is too much control
DS: yes, DWIM or auto might be better
CC: i think having stretch and
compress is enough
... so compress, take an integer number, say you have 2.5 times the dashes, it would do 3 and the compress it to fit
CL: in some cases you don't want to change the lenght of the dashes
CC: if it's closed you keep the last gap, otherwise remove it
CM: my proposal is a little bit different
[general discussion and drawing on whiteboard]
CC: so maybe it's more about keeping the last gap or not
DS: which case are you optimizing for CM?
CM: maybe we should get rid of compress, and just have stretch?
CC: both are useful, if you end
in the middle of a dashpattern
... it's like a rounding
CL: whichever one has the least change
DS: people probably rather want
dashes that are of equal size
... and the rect corner thing
CM: my proposal addresses that,
bottom half of the page
... i'm unconfortable with having 4 options
CL: people that are pushing for this want more control
DH: as long as there's good fallback behavior
CM: you want auto to be something like round gaps
CL: you want auto to do what is done currently, otherwise it would change current behaviour
CC: are dashes fixed? if you
increase length of path, you get more and more dashes and gaps,
... if you animate it it will blip when it does the rounding to an integer number of dashes/gaps
CM/CL: yes, that's unavoidable
CC: maybe we can start with this proposal, even if it's too much control
RESOLUTION: the proposal for stroke-dash-adjust pending modification for edge-cases (open path vs closed path, impossible compression of gaps, round vs ceil)
<scribe> ACTION: cameron to update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action08]
<trackbot> Created ACTION-3163 - Update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution [on Cameron McCormack - due 2011-11-04].
<cyril> s/round vs ceil)/round vs ceil) is accepted/
<cyril> scribe: cyril
CL: Sairus Patel was yet another person who raised the problem that colors are baked in, and Params could be a solution
DS: I thougt about this use case before
CM: I'm curious how the params
would be set
... in the font URL or on the text element
ED: it would be nice to pass it on the whole font face
CC: what's the status of the spec right now? stable ?
DS: no, there are 2 models and I
can't decide which one is the best
... I don't define what happens when the types are wrong, it's not strongly typed
CM: in the first you declare the
params that the document is expected and you provide
... in the second, you don't provide fallback but the use of the param has to provide fallback
DS: I think the one implemented by Adobe is the one in TR, with one level of indirection
CM: I can go through the specs and give my opinion
<scribe> ACTION: heycam to review the Parameters specs and comment appropriately [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action09]
<trackbot> Created ACTION-3164 - Review the Parameters specs and comment appropriately [on Cameron McCormack - due 2011-11-04].
CM: We've resolved that's a req
for SVG 2
... but Chris found some conflicting pages
CL: we agreed to have CatmullRom
Curves with a tension parameter
... but for CR curves the tension is 0
... if not 0, it's a Cardinal curve
... but no one implements that
... can we resolve CR without tension ?
CL: it fits better in the path syntax
RESOLUTION: We will have Catmull Rom Curves (with 0 tension) in SVG 2
CC: can you close smoothly a CR curve, without a Z ?
DS: I don't know
CL: (drawing a gradient
interpolation on board)
... linear interpolation of color creates a band
... as well as using a path syntax, we could add smoothness
CC: we should add this to the Advanced Gradients Req doc
CL: in our interpolation methods for animation, we don't guarantee that there is no discontinuity in the speed
<scribe> ACTION: Cyril to edit the Advanced Gradients requirements document to include support for smooth gradients [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action10]
<trackbot> Created ACTION-3165 - Edit the Advanced Gradients requirements document to include support for smooth gradients [on Cyril Concolato - due 2011-11-04].
CL: for animation, we have
ease-in and ease-out but that's it
... I'm proposing that we have a way to have smooth interpolation for animations
... in 2d, we could have a motion path
... with smooth animation
CC: the general idea of having a better interpolation, smoother, is interesting
CL: the advantage is reusing the same syntax as CR curves
JY: in the context of CSS animations, there are problems with smooth interpolation, CR curves could be a solution
RESOLUTION: SVG 2 should have smooth interpolation of animation values and gradient stuff, such as Catmull Rom curves
<scribe> ACTION: heycam to add all resolutions of the pre-TPAC F2F meeting minutes to the SVG 2 Req document [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action11]
<trackbot> Created ACTION-3166 - Add all resolutions of the pre-TPAC F2F meeting minutes to the SVG 2 Req document [on Cameron McCormack - due 2011-11-04].
DS: that could be interesting to interpolate between paths that don't have the same number of segments
CL: rather that adding nurbs into path, we could have a conversion
CC: According to Tav, we could have S-basis curves
CM: in the cases of dash a path with corners, like a rectangle, we want to control the dash
CC: how do you define a corner
CM: I don't think we can reuse existing dash, so I came up with a new one
CL: we have to see with users of dashes how much distortion of the path is acceptable
DS: in his original proposal, the
dashes start at the corner, and to have it balanced on both
sides of the corner, you have to use offset
... I'm proposing that the default is when the center of the dash is on the corner
... and the offset can still be used
... I agree with Chris, we need to check with people using dashes\
CM: graphics libraries tend to
not support dashes adjustment and you have to do it
... this is very similar to marker start, mid and end
DS: this would work well with rounded rectangles
CL: we should put this as a starting proposal
CM: I'll put more examples on the
... and mail Andreas and CGM people
CL: and Bessetti people
<heycam> s/and Bessetti people/and Ann Bassetti/
<heycam> ScribeNick: heycam
<cyril> CM: wondering about the stroking of a shared path
<cyril> CL: the vector effect constructs the fill and the stroking is done afterwards
<cyril> ... so stroking should not happen twice
<cyril> (drawing on the board)
<cyril> CM: the issue I see is how the stroke happens on joining paths
<cyril> CL: you could use vector effect (union, intersection) to define the right stroke
<cyril> ... but the result would be a path and could not be stroke
<cyril> s/could not be stroke/could not be dashed/
DS: you may also want to dash the different edges of the countries, how do you control that?
RESOLUTION: We will have a solution to shared path segments in SVG2.
<scribe> ACTION: Chris to talk to map and CGM people about requirements for dashing and shared path edges [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action12]
<trackbot> Created ACTION-3167 - Talk to map and CGM people about requirements for dashing and shared path edges [on Chris Lilley - due 2011-11-05].
<ed> previous resolution: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#We.27ll_consider_the_connector_proposal
CC: We already have a resolution to consider it
DS: we will leave it open
[doug draws examples on board]
CM: how is this different from mesh transforms?
CL: it's affecting the underlying geometry
CM: I am still wondering how this
is different from general e.g. mesh transforms
... I don't know if this is a subset of mesh transforms, which we said no on
... if this is a sufficiently subset of functionality, that is simpler enough, then maybe we can say yes to this
... but it's not clear to me that is the case
DS: I would be happy with it in a separate specification
CC: can we have a separate spec with these skeleton frames, and mesh transforms?
RESOLUTION: We will not have skeleton paths in SVG2, but we will work on it in a separate module.
DS: I have seen some really cool things done with replicate
CC: I think it's almost too
... the problem I can see is that the browser will have difficulties handling the result and optimising it
... if you end up with many paths, you can do an extrusion, but there are many ways you can do an extrusion
ED: depends if you generate DOM
... could be cheaper not to generate additional exposed DOM nodes
CC: the replicate proposal is just a single element AIUI
CL: it effectively makes a bunch of shadow dom elements
DS: it makes me wonder if it can be done with Web Components
<ChrisL> <script type ="text/logo" />
s/Web Components/Component Model/
CM: I share that concern
JY: it makes it a lot easier to
do something ridiculous
... like replicate a trillion times
CL: if you are adding 1000s, it would be better if it's not in the DOM
CM: there's a balance between usefulness and complexity here, and I'm not really sure it lies on the right side of that to include in SVG2
DS: all these things on the page
look really cool
... the tubefy thing interests me
CM: but I think this is the wrong solution to achieve that gradient effect
ED: the tubefy thing is what I've heard the most requests for
DS: the extruded text also
... but I don't see people wanting to do this in production apps
... for 3D things they would use WebGL
CM: I love these effects, but I am worried about this not being practical enough for the complexity of a performant implementation
ED: the script library is very small
JY: have other people been using his script?
DS: that tubefy example is Israel
Eisenberg redoing his gradient worm with replicate
... I think that is a good point, is anyone else doing stuff with it?
JY: if people use this script library, then it's a good hint to include the functionality, because you get the advantage of not needing DOM nodes in the native implementation
DS: two things would change my
... one, if we saw an uptake of people using the script library to solve the problems they have
... and two, if we saw more concrete examples of practical uses of the library
... using it to solve a problem
CC: we have browsers, and authoring tools in the group, and we haven't had any people crying out that they really want this
RESOLUTION: We will not include replicate in SVG2 unless accompanied by concrete use cases and demonstration of author/implementor interest.
DS: I would like to see a spec just to see if it can yield other solutions, to see what emerges from it
DS: there are two aspects of
... there's the replicating patterns, which is more ambitious
... and the other is Cameron's proposal, which does not include repetition
CM: I think we need to see some
justification for extending my turtle graphics to the more
... since mine are grounded in particular use cases, for example animating angles between path segments, easily creating pie chart shapes, etc.
... general logo-like graphics, I'm not sure what the practical reason to include that
RESOLUTION: We will not include general turtle graphics in SVG2 without examples of practical reasons to do so.
CM: this is just catmull-rom
... which we have already decided to include
RESOLUTION: We will include smooth path between points functionality in SVG2.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/CC/CM/ Succeeded: s/heycam/CM/ Succeeded: s/heycam/CM/ Succeeded: s/transforming a curve/transforming a straight line/ FAILED: s/round vs ceil)/round vs ceil) is accepted/ FAILED: s/and Bessetti people/and Ann Bassetti/ FAILED: s/could not be stroke/could not be dashed/ FAILED: s/Web Components/Component Model/ Succeeded: s/that/the performance concern/ Found ScribeNick: ChrisL Found ScribeNick: dholbert Found ScribeNick: ed Found Scribe: cyril Inferring ScribeNick: cyril Found ScribeNick: heycam ScribeNicks: ChrisL, dholbert, ed, cyril, heycam WARNING: Replacing list of attendees. Old list: +1.650.693.aaaa [IPcaller] AD New list: Doug_Schepers +1.650.693.aaaa WARNING: Replacing list of attendees. Old list: Doug_Schepers +1.650.693.aaaa New list: +1.650.693.aaaa tbah WARNING: Replacing list of attendees. Old list: +1.650.693.aaaa tbah New list: tbah Default Present: tbah Present: Chris Erik Daniel_Holbert Jen Jun Takagi-san Cyril Vincent Cameron Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda Found Date: 28 Oct 2011 Guessing minutes URL: http://www.w3.org/2011/10/28-svg-minutes.html People with action items: cameron chris chrisl cm cyril heycam tav[End of scribe.perl diagnostic output]