20:20:52 RRSAgent has joined #svg 20:20:52 logging to http://www.w3.org/2016/11/24-svg-irc 20:20:54 RRSAgent, make logs public 20:20:57 Zakim, this will be GA_SVGWG 20:20:57 ok, trackbot 20:20:57 Meeting: SVG Working Group Teleconference 20:20:57 Date: 24 November 2016 20:21:24 Chair: Nikos 20:21:30 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0017.html 20:21:32 present+ nikos 20:23:39 present+ AmeliaBR 20:28:12 stakagi has joined #svg 20:33:31 present+ Tav 20:35:52 present+ stakagi 20:36:09 https://lists.w3.org/Archives/Public/public-media-capture/2016Nov/0054.html 20:36:15 Scribe: nikos 20:38:16 Topic: Workflow for SVG 2 CR changes 20:38:31 https://github.com/w3c/svgwg/wiki/Guidelines-for-updating-SVG-2-CR 20:38:37 nikos: earlier in the week I posted a link to this wiki 20:38:48 ... it just lays out the procedure for updating the SVG 2 CR 20:40:08 https://svgwg.org/svg2-draft/changes.html#structure 20:40:46 nikos: If you look just above that anchor, you'll see one I did earlier in the week 20:40:57 ... happy to adjust the formatting 20:41:38 ... Here's a PR I created earlier as an example 20:41:39 https://github.com/w3c/svgwg/pull/296 20:44:17 nikos: If you're happy that the PR is ok, checking against the review guidelines, then you can just go ahead and merge 20:45:23 nikos: I would be happy for the person who merges to delete the branch - you can always restore and submitter has a copy 20:46:07 Topic: patternTransform browser implementations do not match spec 20:46:18 https://github.com/w3c/svgwg/issues/293 20:46:33 AmeliaBR: Nikos posted a new comment, which I haven't read yet 20:46:38 nikos: I hope it's correct (ish) 20:46:54 AmeliaBR: I agree with your thinking that we should consider patternContentUnits as a special automatic viewBox 20:47:03 ... so think of content coordiante system the way we do with viewBox 20:47:23 ... that's important because for all other cases in SVG, if there's a transform and a viewBox - the transform applies in the outside coordinate system and not the inside coordinate system 20:47:39 ... if we're being consistent iwth patternTransform, it would apply in the pattern tile coordinate system 20:48:02 ... the other part that is fairly clearly defined is that the transform is supposed to apply after you convert to objectBoundingBox if neccessary 20:48:09 ... assuming that's obb for patternUnits 20:48:19 nikos: Yeah that's the way I understood it as well 20:48:42 AmeliaBR: I'd have to sit down and work it out - for patterns there's also the translation effect of actually tiling 20:48:54 ... not sure where in the sequence of transforms that would work most logically 20:49:10 I think most of the browsers are consistent when patternUnits is userSpaceOnUse 20:49:20 ... so if we double check what they'r edoing there and make sure it all makes sense 20:50:01 AmeliaBR: I like the idea of focusing on clarification through the test suite, then if we get push back from browsers we can let someone pull up another proposal 20:50:05 Tav: sounds like a good idea to me 20:50:16 ... please make tests work in Inkscape 20:51:36 RESOLUTION: pattern transforms are intended to work as described in SVG 1.1 (though clarification of some cases is required) - browser behaviour is wrong 20:52:05 nikos: Next question if who will make tests 20:52:20 AmeliaBR: Would be good to look at what existed in 1.1 and why was this falling through 20:52:41 nikos: I'll look at what was there and convert those options 20:53:20 ... and I'll look at making some more tests and we can talk about that once I've started and maybe divvy up the cases 20:54:08 Topic: Testing - anti aliasing issues 20:54:45 https://github.com/w3c/web-platform-tests/pull/4015/ 20:55:02 In this PR there's some tests where the SVG test and the SVG reference have some subtle anti aliasing differences 20:55:17 ... this is caused by the numerous levels of transform that the graphics in the test go through 20:55:48 ... it should theoretically possible to use a set of values that give a nice predictable anti aliased result, that can then be replicated in the reference 20:56:10 ... but doing that is really hard, and it's not really scalable 20:56:32 ... it's going to be an ongoing problem 20:56:43 AmeliaBR: due to the nature of the different graphics that we are use to test and reference 20:56:54 ... I don't really have any suggestions or resolutions at the moment 20:57:03 ... when I ran the tests through webkit they did fail 20:57:16 ... webkit test runner reported 0.1% pixel difference 20:57:53 Tav: How did you run the tests? 20:58:00 nikos: Through the webkit test infrastructue 20:58:18 ... you need a checkout of webkit, you build it, then you use ./Tools/scripts/run-webkit-tests 20:58:22 ... and specify your tests 20:58:37 ... for webkit references need a different name than in web-paltform-tests 20:58:51 ... it's fairly simple if you have all the bits ready to go 20:59:01 AmeliaBR: InkScape currently use PNG references? 20:59:06 Tav: we don't have automated testing right now 20:59:19 ... have had it in the past - the reference doesn't really matter 20:59:23 ... can be svg or png 20:59:50 ... what I would do for the amount of tests we have is to go through them visually 21:00:20 AmeliaBR: our issue is when people are going through manually, they can say these look the same - but utilities that test pixel values may complain about hairline differences 21:01:05 nikos: So my plan is to do some investigation about how browsers handle little differences 21:01:15 ... and talk to heycam and see if he has thoughts on the matter 21:01:37 AmeliaBR: I looked at wpt - most are script tests, but some canvas tests are ref tests 21:01:44 ... those ref tests replace canvas element with a png 21:02:01 ... assume the png was generated from the canvas - it must have come up at some point before 21:03:04 Tav: can you set the threshold? 21:03:18 nikos: You can at the project level, not sure for individual tests 21:03:25 AmeliaBR: threshold is an icky way to do things 21:04:23 nikos: one sugggestion I got from someone at work is to convert output to 1bpp and ignore 1 pixel around the boundary 21:04:31 Tav: SVG spec is only accurate to 0.5 px anyway 21:05:13 AmeliaBR: it might be worth specifically pinging people from other implementations about how internal tools handle subtle differences 21:05:21 ... only other option is to go with png reference 21:05:27 ... which is more reliable for any given implementation 21:05:40 ... but there'll be more differences from one implementation to the next 21:05:46 nikos: And one platform to the next even 21:06:28 nikos: I'll keep chugging along with this, but there's plenty of other tests we can convert that won't exhibit the problem 21:07:54 RRSAgent, make minutes 21:07:54 I have made the request to generate http://www.w3.org/2016/11/24-svg-minutes.html nikos 21:20:19 I have received an indication from those who are considering implementation of vector effects that the formula and illustration of the vector effects chapter of SVG 2 CR are broken. 21:22:53 Have you had a chance to look into it stakagi? Can you make a GitHub issue? 21:27:14 roger that.