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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control
00:14:17 [heycam]: CM: this one sounds more interesting to me
00:15:38 [ChrisL]: http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming
00:20:33 [heycam]: RESOLUTION: We will support Level of Detail control in SVG2.
00:21:04 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_transform.3D.22.22_to_.3Csvg.3E
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switching
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_referencing_root_external_files_with_.3Cuse.3E
00:33:43 [heycam]: ED: next, allow referencing root external files with use
00:33:56 [ChrisL]: ISSUE-2238:
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Parameters
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 sip:zakim@voip.w3.org), heycam
00:51:24 [Zakim]: - +1.650.693.aaaa
00:51:26 [Zakim]: -AD
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]: +Doug_Schepers
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]: -Doug_Schepers
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 http://www.w3.org/2011/10/28-svg-minutes.html 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]: shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/
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]: thanks
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 http://www.w3.org/2011/10/28-svg-irc
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]: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Custom_data-.2A_attributes
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]: See http://www.w3.org/2011/10/28-svg-irc#T16-33-21
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_certain_HTML_attributes_used_in_microformats
16:36:04 [ChrisL]: Topic: Consider adding certain HTML attributes used in microformats
16:36:15 [ChrisL]: ISSUE-2048?
16:36:15 [trackbot]: ISSUE-2048 -- Consider adding certain HTML attributes used in microformats -- raised
16:36:15 [trackbot]: http://www.w3.org/Graphics/SVG/WG/track/issues/2048
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_relaxing_case_sensitivity_of_presentation_attribute_values
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Fluorescent_colours.2Fextended_colour_specifiers
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]: http://dev.w3.org/SVG/modules/color/publish/SVGColor.html
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]: http://dev.w3.org/SVG/modules/color/master/SVGColor.html
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]: (agreed)
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_stroke
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 sip:zakim@voip.w3.org), heycam
17:48:49 [Zakim]: Team_(svg)17:47Z has now started
17:48:56 [Zakim]: + +1.650.693.aaaa
17:48:59 [Zakim]: +tbah
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_rounded_rect_corners
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]: ref(svg,x,y)?
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width
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]: http://tavmjong.free.fr/SVG/SVGOpen2011/INKSCAPE/svg_2011_inkscape.svg
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Perpendicular_stroke
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]: s/CC/CM/
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position
18:14:11 [dholbert]: topic: define behavior of stroke-dasharray
18:14:14 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Define_behaviour_of_stroke-dasharray
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Adaptive_stroking
18:19:18 [dholbert]: heycam, to be able to do things like align dashes exactly on corner of a rectangle
18:19:24 [dholbert]: s/heycam/CM
18:19:30 [dholbert]: s/heycam/CM/
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hatch_fills
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]: http://en.wikipedia.org/wiki/Hatching
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]: http://fr.wikipedia.org/wiki/Hachure has more detail actually
18:28:43 [dholbert]: topic: arbitrary fill
18:28:44 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Arbitrary_fill
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SVG_using_WebGL_filters
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_an_href_to_the_style_element_to_link_to_external_stylesheets
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_HTML5_style-element_attributes_to_SVG.27s_style_element
18:46:20 [dholbert]: CM: this is e.g. 'media' and 'scoped' attributes
18:46:39 [heycam]: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element
18:48:01 [ChrisL]: http://www.w3.org/TR/html5/semantics.html#the-style-element
18:49:52 [Zakim]: -tbah
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms
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]: -tbah.a
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 sip:zakim@voip.w3.org), heycam
18:53:06 [tbah]: Thanks
18:53:45 [Zakim]: Team_(svg)18:52Z has now started
18:53:52 [Zakim]: +tbah
18:53:54 [Zakim]: +tbah.a
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]: http://blockses.appspot.com/1246403
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Other_2.5D_effects
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Support_getting_bounding_boxes_that_include_stroke_and.2For_markers
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_allowing_rotations_to_be_relative_to_their_bounding_box_center
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]: -tbah.a
19:31:06 [Zakim]: -tbah
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]: action-1?
21:03:05 [trackbot]: ACTION-1 does not exist
21:03:10 [ChrisL]: action-100?
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]: http://www.w3.org/TR/SVGMobile12/single-page.html#coords-ConstrainedTransformations
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]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position
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]: http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html
21:45:05 [heycam]: http://lists.w3.org/Archives/Public/www-svg/2011Sep/0062.html
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: 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
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]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment
22:09:58 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment
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]: ...it'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]: http://www.w3.org/TR/SVGParam/
23:16:23 [shepazu]: http://dev.w3.org/SVG/modules/param/master/SVGParam.html
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]: http://www.w3.org/Graphics/SVG/WG/wiki/Path_Enhancements
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]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
23:55:23 [cyril]: Topic: shared paths
23:55:32 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shared_paths
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: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#We.27ll_consider_the_connector_proposal
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]: http://cs.sru.edu/~ddailey/svg/lizard2.svg
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]: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-PatternAlongPath.html
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]: See http://www.w3.org/2011/10/28-svg-irc#T00-24-21
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]: http://en.wikipedia.org/wiki/Logo_%28programming_language%29
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]: http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
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 http://www.w3.org/2011/10/28-svg-minutes.html heycam
01:06:02 [heycam]: RRSAgent, bye
01:06:02 [RRSAgent]: I see 11 open action items saved in http://www.w3.org/2011/10/28-svg-actions.rdf :
01:06:02 [RRSAgent]: ACTION: ChrisL to look at global attributes [1]
01:06:02 [RRSAgent]: recorded in http://www.w3.org/2011/10/28-svg-irc#T16-39-39
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 http://www.w3.org/2011/10/28-svg-irc#T16-57-40
01:06:02 [RRSAgent]: ACTION: ChrisL to edit the svg colormanagemtn spec into a chapter in SVG2 [3]
01:06:02 [RRSAgent]: recorded in http://www.w3.org/2011/10/28-svg-irc#T17-34-05
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 http://www.w3.org/2011/10/28-svg-irc#T17-58-38
01:06:02 [RRSAgent]: ACTION: CM to put the stroke-position proposal into the SVG2 spec [5]
01:06:02 [RRSAgent]: recorded in http://www.w3.org/2011/10/28-svg-irc#T22-09-22
01:06:02 [RRSAgent]: ACTION: cameron to put the stroke-position proposal into the SVG2 spec [6]
01:06:02 [RRSAgent]: recorded in http://www.w3.org/2011/10/28-svg-irc#T22-09-28
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 http://www.w3.org/2011/10/28-svg-irc#T22-42-33
01:06:02 [RRSAgent]: ACTION: heycam to review the Parameters specs and comment appropriately [8]
01:06:02 [RRSAgent]: recorded in http://www.w3.org/2011/10/28-svg-irc#T23-17-18
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 http://www.w3.org/2011/10/28-svg-irc#T23-28-53
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 http://www.w3.org/2011/10/28-svg-irc#T23-42-55
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 http://www.w3.org/2011/10/28-svg-irc#T00-09-52
01:06:05 [heycam]: Zakim, bye
01:06:05 [Zakim]: Zakim has left #svg