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=https%3A%2F%2F2.gy-118.workers.dev/%3A443%2Fhttp%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