20:27:52 <RRSAgent> RRSAgent has joined #svg
20:27:52 <RRSAgent> logging to http://www.w3.org/2015/04/09-svg-irc
20:27:54 <AmeliaBR> AmeliaBR has joined #svg
20:27:54 <trackbot> RRSAgent, make logs public
20:27:54 <Zakim> Zakim has joined #svg
20:27:56 <trackbot> Zakim, this will be GA_SVGWG
20:27:56 <Zakim> ok, trackbot; I see GA_SVGWG()4:30PM scheduled to start in 3 minutes
20:27:57 <trackbot> Meeting: SVG Working Group Teleconference
20:27:57 <trackbot> Date: 09 April 2015
20:28:37 <Zakim> GA_SVGWG()4:30PM has now started
20:28:43 <Zakim> +[IPcaller]
20:28:49 <ed> Zakim, [IP is me
20:28:49 <Zakim> +ed; got it
20:29:21 <Zakim> +[IPcaller]
20:29:24 <heycam> Zakim, [ is me
20:29:24 <Zakim> +heycam; got it
20:29:59 <Zakim> +??P7
20:30:09 <AmeliaBR> zakim ??P7 is me
20:30:20 <AmeliaBR> zakim, ??P7 is me
20:30:20 <Zakim> +AmeliaBR; got it
20:30:22 <Smailus> Smailus has joined #svg
20:30:54 <Zakim> +[Microsoft]
20:31:04 <Rossen> zakim, Microsoft is me
20:31:04 <Zakim> +Rossen; got it
20:31:07 <Zakim> +Thomas_Smailus
20:31:09 <heycam> http://www.w3.org/blog/news/archives/4585?pk_campaign=feed&pk_kwd=three-drafts-published-by-the-svg-working-group
20:31:34 <Zakim> +??P11
20:31:42 <stakagi> zakim, ??P11 is me
20:31:42 <Zakim> +stakagi; got it
20:31:52 <heycam> Chair: Cameron
20:32:27 <heycam> Agenda: http://lists.w3.org/Archives/Public/www-svg/2015Apr/0007.html
20:32:31 <heycam> Regrets: Nikos
20:34:16 <AmeliaBR> Scribenick: AmeliaBR
20:34:56 <AmeliaBR> TOPIC:  Update on Telcon Time Survey
20:35:31 <AmeliaBR> Cam: Brian had asked if we could maybe have same day but different time.
20:35:59 <AmeliaBR> Rossen: Thursday works best for us (at MS) Tuesday I have a number of standard meetings
20:36:12 <Zakim> +??P0
20:36:32 <AmeliaBR> Cam: Well, I can send out another straw poll and we'll see what people's availability is.
20:36:39 <Tav> zakim, ??P0 is me
20:36:39 <Zakim> +Tav; got it
20:36:51 <AmeliaBR> TOPIC: SVG 2 Open Issues Discussion
20:37:02 <Zakim> +[IPcaller]
20:37:20 <AmeliaBR> Cam: I though we could start with the painting chapter, which I've made significant changes to
20:37:30 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Needing_discussion_10
20:38:06 <AmeliaBR> Cam: Some of these we may have discussed face-to-face, but never got integrated in the spec
20:38:33 <Zakim> +Doug_Schepers
20:38:53 <AmeliaBR> ... First is issue 18, re stroke on text.  We now have a detailed implementation instructions on stroking, we may need to define it better
20:39:12 <AmeliaBR> ... in particular with respect to stroke dashing.  Where do the dashes start?
20:39:24 <AmeliaBR> ... I don't think browsers implement this interoperably.
20:39:55 <AmeliaBR> Rossen: This is also one of the issues on our sheet.  Our proposal was to leave it up to the implementation.
20:40:32 <AmeliaBR> ... There are different primitive graphics programs that can be used cross-platform, any sort of restrictions will go against the potential for optimization.
20:40:53 <AmeliaBR> Cam: To be clear, you want flexibility in the stroking implementation even for basic shapes like ellipse?
20:41:51 <AmeliaBR> Rossen: Yes, because many of the primitive libraries do not even provide that information to the web platform.  In some cases, basic shapes are available from the GPU, and this would affect that.
20:42:38 <shepazu> agenda+ Graphical Web/SVG Open
20:42:53 <AmeliaBR> ... We should leave this up to implementations.  Unless we impose strict requirements that will invalidate all the potential optimizations, we cannot force interoperability about where the dashes start.
20:43:02 <ed> agenda+  CORS-in-svg, https://lists.w3.org/Archives/Public/www-svg/2015Mar/0139.html
20:44:10 <AmeliaBR> Ed (?):  Are there differences in implementations for basic shapes?
20:44:28 <AmeliaBR> Rossen: In some cases, and especially for text.
20:44:45 <ed> s/Ed (?)/Tav (?)/
20:45:25 <AmeliaBR> ... We're 20 years into a web platform with different behaviors for CSS borders, because of different platform behaviors for rectangles.
20:45:46 <AmeliaBR> Tav: Are there any differences for basic lines and paths?
20:46:05 <AmeliaBR> Bogdan: For lines, there isn't a problem, because there is a clear start and end.
20:47:10 <AmeliaBR> ... What we're talking about is basic shapes -- rectangles, circles, ellipse -- where they are implemented by the underlying graphics libraries.  There are no guarantees made, today, by implementations as to where the stroke on those shapes starts.
20:48:01 <AmeliaBR> ... We could add normative text here to make it a requirement, but I don't think implementations will put much effort into making this interoperable.  So then there would be implementation gaps relative to the spec.
20:48:45 <AmeliaBR> Cam:  It's interesting the comparison with CSS dashed borders.  I wonder how much we can define this without affecting optimization.
20:49:28 <AmeliaBR> Bogdan: We have no problem about clearly defining the behavior when the shape is defined by custom points (e.g. path).
20:49:59 <AmeliaBR> Tav: For Inkscape, we draw the basic shapes by implementing them as paths, so there is no difference.
20:50:57 <AmeliaBR> Bogdan: But that is incredibly inefficient if basic shapes already exist in the underlying graphics library.  You *can* always represent shapes as paths, but that doesn't work in all cases, for best optimization.
20:51:38 <AmeliaBR> ... We could define it as a MAY be done this way, but I would not want it to be a MUST.
20:52:36 <AmeliaBR> Tav:  I think everyone can agree that trying to define the start of dash patterns on *text* is useless.  Basic shapes are still a matter of debate.
20:53:40 <AmeliaBR> Bogdan: I would argue that defining the start of an ellipse is also useless.  If it is important, you can define it with a path with a specific start path.  In that case, the start of dashing would be clearly defined and you'd go from there.
20:54:56 <AmeliaBR> Tam:  We have already resolved on path-equivalent definitions for all the shapes, for other purposes.
20:55:14 <Tav> s/Tam/Tav/
20:55:45 <AmeliaBR> ED:  There are certainly use cases.  E.g., to stroke some sides of a rectangle by explicitly setting the dash array.  But you need to know where those dashes start.
20:56:14 <AmeliaBR> Bogdan:  But anyone who really needs that control could use a path themselves.
20:56:54 <AmeliaBR> ED: But why would it be difficult for an implementation to adjust the offset of the dash pattern to match a defined start point?
20:57:24 <AmeliaBR> ... Not for text, we agreed on that, but for basic shapes I think we can and should define where a stroke starts.
20:59:16 <AmeliaBR> Rossen:  As I said before, we could add a specific requirement to the spec, but I think that would increase the likelihood of non-conforming implementations, since I don't think implementations will make the necessary changes.
20:59:53 <AmeliaBR> ED:  I don't see this as a major implementation problem.  But you're saying it would be a problem on Windows.
20:59:57 <Rossen> zakim, who is noisy
20:59:57 <Zakim> I don't understand 'who is noisy', Rossen
21:00:29 <AmeliaBR> Rossen: I'm saying I'm not sure we won't *not* have a problem
21:01:03 <heycam> Zakim, who is noisy?
21:01:14 <Zakim> heycam, listening for 10 seconds I could not identify any sounds
21:01:42 <AmeliaBR> Cam: OK, so we've all agreed that we won't specify it for text.  For basic shapes, the question is *how* much variability is acceptable.
21:01:49 <Rossen> zakim, mute all
21:01:49 <Zakim> sorry, Rossen, I do not know which phone connection belongs to all
21:01:58 <Rossen> zakim, mute everyone
21:01:58 <Zakim> sorry, Rossen, I do not know which phone connection belongs to everyone
21:02:01 <shepazu> Zakim, mute heycam
21:02:01 <Zakim> heycam should now be muted
21:02:05 <Rossen> zakim, mute yourself
21:02:05 <Zakim> sorry, Rossen, I do not know which phone connection belongs to yourself
21:02:06 <Smailus> not me... still noisy when I muted
21:02:09 <shepazu> Zakim, mute shepazu
21:02:09 <Zakim> sorry, shepazu, I do not know which phone connection belongs to shepazu
21:02:20 <shepazu> Zakim, mute Tav
21:02:20 <Zakim> Tav should now be muted
21:02:23 <AmeliaBR> ... I think the next step is to do testing to see how much difference between the implementations currently exists.
21:02:31 <shepazu> Zakim, mute AmeliaBR
21:02:31 <Zakim> AmeliaBR should now be muted
21:02:39 <heycam> Zakim, who is on the call?
21:02:39 <Zakim> On the phone I see ed, heycam (muted), AmeliaBR (muted), Rossen, Thomas_Smailus, stakagi, Tav (muted), birtles, Doug_Schepers
21:02:55 <Rossen> zakim, mute ed
21:02:55 <Zakim> ed should now be muted
21:03:00 <Rossen> there you go
21:03:04 <Smailus> Ed it is.
21:03:15 <heycam> Zakim, unmute heycam
21:03:15 <Zakim> heycam should no longer be muted
21:03:18 <heycam> Zakim, unmute AmeliaBR
21:03:18 <Zakim> AmeliaBR should no longer be muted
21:03:20 <heycam> Zakim, unmute Tav
21:03:20 <Zakim> Tav should no longer be muted
21:03:22 <heycam> Zakim, who is on the call?
21:03:22 <Zakim> On the phone I see ed (muted), heycam, AmeliaBR, Rossen, Thomas_Smailus, stakagi, Tav, birtles, Doug_Schepers
21:04:11 <AmeliaBR> Cam:  I can take the action to test existing implementations on stroke dashing, or maybe Tav could help?
21:05:08 <Zakim> -ed
21:05:38 <AmeliaBR> ACTION: Tav to test browser-interoperability with respect to stroke dashing on basic shapes
21:05:39 <trackbot> Created ACTION-3776 - Test browser-interoperability with respect to stroke dashing on basic shapes [on Tavmjong Bah - due 2015-04-16].
21:06:31 <Zakim> +??P1
21:06:36 <AmeliaBR> Tav:  Did we settle Issue 18, should dashing still work on text?
21:06:53 <AmeliaBR> AmeliaBR: I think the decision was it should, but with no requirements about where the dashes start
21:07:20 <AmeliaBR> Tav: I think that makes sense.  We (Inkscape) certainly implement it, and I've seen it in use on the web.
21:08:32 <AmeliaBR> Rossen:  Yes, without defining a starting point.  That sounds reasonable.
21:09:11 <AmeliaBR> RESOLUTION:  Stroke dashing should work as normal on text, but the specifications will not define the starting point for a dash offset.
21:10:19 <AmeliaBR> Cam:  The other issue that I'd like to discuss in this chapter is Issue 25, with respect to the image-rendering property.  Should we require resampling to be in the linear color space?
21:10:37 <AmeliaBR> ... I'm not sure where this issue comes from, or if it makes sense.
21:11:04 <AmeliaBR> Tav: If you *don't* resample in a linear color space, you can get crazy results sometimes.
21:11:30 <AmeliaBR> ... If you upsample or down-sample something, and you're not using a linear color space, you get the wrong color.
21:11:57 <Tav> http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/index.html
21:12:00 <AmeliaBR> Bogdan:  Can you explain why?
21:12:46 <AmeliaBR> Tav: The above link discusses a lot of the details of color spaces.
21:14:12 <AmeliaBR> ... In the sample on upscaling/ downscaling: as you zoom your browser in and out, the black and white patterns should match the solid gray below them.
21:15:08 <AmeliaBR> s/below them/on the bottom right/.
21:16:05 <AmeliaBR> s/bottom right/bottom left/
21:16:12 <AmeliaBR> s/in and out/out/
21:16:42 <AmeliaBR> ... When you average the black and white points, in a linear space you should get 50% gray.  In an sRGB color space, you get the gray on the bottom right, #bbbbbb instead
21:18:14 <AmeliaBR> Tav:  This is why, for filters, the basic color space is linear.  The only reason it isn't the standard for all SVG is because mobile browsers couldn't do it.
21:18:32 <AmeliaBR> Bogdan:  But if implementations can't do it, do we really want to require it?
21:19:00 <AmeliaBR> Tav:  We could require it for "high-quality" viewers.  But at this point I would be happy just recommending it.
21:21:10 <glenn> glenn has joined #svg
21:21:17 <AmeliaBR> AmeliaBR: This is in the context of `image-rendering`.  Under what value of that hint property would this apply?
21:21:55 <AmeliaBR> Tav:  The new image-rendering CSS spec doesn't have anything to do with color, it has to do with pixelation and the sampling algorithm you use?
21:22:32 <AmeliaBR> AmeliaBR: Okay, well then are we removing the SVG optimizeQuality/optimizeSpeed options?  Should the color issue be taken up with CSS?
21:22:56 <AmeliaBR> Tav:  I think it is orthogonal.  We can still have a recommendation.
21:23:31 <AmeliaBR> RESOLUTION:  SVG 2 should recommend but not require that image resampling is done in a linear color space.
21:24:59 <shepazu> September 23-26
21:25:36 <AmeliaBR> shepazu:  Are we likely to have a face to Face as part of the Graphical Web conference?  It's later than usual this year, so it is close to TPAC.
21:25:44 <shepazu> https://www.graphicalweb.org/2015/
21:25:52 <shepazu> September 23-26 2015
21:25:52 <shepazu> Pittsburgh, Pennsylvania, USA
21:26:03 <AmeliaBR> ... in Pittsburg, so it is relatively local for a lot of members
21:26:41 <AmeliaBR> ... If there are enough people who will be there, we could have an informal mini face to face
21:27:59 <shepazu> shepazu, AmeliaBR, Tav, maybe Rossen
21:28:53 <shepazu> please submit talks for GRaphical Web
21:28:57 <AmeliaBR> TOPIC: more SVG 2 issues
21:29:07 <jcraig> jcraig has joined #svg
21:29:12 <shepazu> s/ GRaphical Web/ Graphical Web/
21:29:45 <AmeliaBR> Rossen:  The `hasFeature` method.  I'm not sure it has any use.
21:29:51 <birtles> https://dom.spec.whatwg.org/#dom-domimplementation-hasfeature
21:30:17 <AmeliaBR> ... it always returns true.
21:30:57 <AmeliaBR> Cam: I think the DOM spec requires that now.
21:31:25 <AmeliaBR> AmeliaBR:  With the exception of the SVG feature strings, since those had useful implementations based on switch and requiredFeature.
21:31:49 <AmeliaBR> Rossen:  But we tried it with new features, like "SVG3", and it always returned true.
21:32:21 <birtles> https://lists.w3.org/Archives/Public/www-svg/2014Sep/0037.html
21:33:17 <AmeliaBR> AmeliaBR: So, anything other than the feature strings in SVG 1.1 is useless.
21:33:56 <AmeliaBR> shepazu: So, this is basically a broken feature.
21:35:03 <AmeliaBR> Rossen:  Can we therefore resolve to remove this appendix?
21:35:27 <AmeliaBR> AmeliaBR:  Would that mean deprecating the SVG 1.1 tests, because those might be currently used.
21:35:44 <AmeliaBR> ... Although the only example I can think of doesn't actually use it correctly.
21:36:39 <AmeliaBR> Cam:  Either way, the `hasFeature` belongs in the DOM spec, and this section was just describing how it worked for SVG.
21:37:10 <AmeliaBR> ... I think we can safely just remove it.
21:37:54 <AmeliaBR> RESOLUTION:  Remove all wording suggesting that you can use the DOM `hasFeature` method
21:38:07 <Zakim> -Thomas_Smailus
21:38:24 <Zakim> -heycam
21:38:26 <Zakim> -Tav
21:38:28 <Zakim> -birtles
21:38:29 <Zakim> -stakagi
21:38:30 <Zakim> -Rossen
21:38:47 <Zakim> -AmeliaBR
21:38:56 <Zakim> -Doug_Schepers
21:39:08 <Zakim> -ed
21:39:10 <Zakim> GA_SVGWG()4:30PM has ended
21:39:10 <Zakim> Attendees were [IPcaller], ed, heycam, AmeliaBR, Rossen, Thomas_Smailus, stakagi, Tav, birtles, Doug_Schepers
21:39:33 <AmeliaBR> RRSAgent, publish the minutes
21:39:33 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/09-svg-minutes.html AmeliaBR
21:48:34 <jcraig> jcraig has joined #svg
22:22:06 <jcraig> jcraig has joined #svg
22:44:49 <jcraig> jcraig has joined #svg
23:04:20 <jcraig> jcraig has joined #svg
23:37:08 <jdaggett> jdaggett has joined #svg