IRC log of svg on 2011-10-28

Timestamps are in UTC.

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