IRC log of svg on 2016-11-24

Timestamps are in UTC.

20:20:52 [RRSAgent]
RRSAgent has joined #svg
20:20:52 [RRSAgent]
logging to http://www.w3.org/2016/11/24-svg-irc
20:20:54 [trackbot]
RRSAgent, make logs public
20:20:57 [trackbot]
Zakim, this will be GA_SVGWG
20:20:57 [Zakim]
ok, trackbot
20:20:57 [trackbot]
Meeting: SVG Working Group Teleconference
20:20:57 [trackbot]
Date: 24 November 2016
20:21:24 [nikos]
Chair: Nikos
20:21:30 [nikos]
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0017.html
20:21:32 [nikos]
present+ nikos
20:23:39 [AmeliaBR]
present+ AmeliaBR
20:28:12 [stakagi]
stakagi has joined #svg
20:33:31 [Tav]
present+ Tav
20:35:52 [stakagi]
present+ stakagi
20:36:09 [nikos]
https://lists.w3.org/Archives/Public/public-media-capture/2016Nov/0054.html
20:36:15 [nikos]
Scribe: nikos
20:38:16 [nikos]
Topic: Workflow for SVG 2 CR changes
20:38:31 [nikos]
https://github.com/w3c/svgwg/wiki/Guidelines-for-updating-SVG-2-CR
20:38:37 [nikos]
nikos: earlier in the week I posted a link to this wiki
20:38:48 [nikos]
... it just lays out the procedure for updating the SVG 2 CR
20:40:08 [nikos]
https://svgwg.org/svg2-draft/changes.html#structure
20:40:46 [nikos]
nikos: If you look just above that anchor, you'll see one I did earlier in the week
20:40:57 [nikos]
... happy to adjust the formatting
20:41:38 [nikos]
... Here's a PR I created earlier as an example
20:41:39 [nikos]
https://github.com/w3c/svgwg/pull/296
20:44:17 [nikos]
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]
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 [nikos]
Topic: patternTransform browser implementations do not match spec
20:46:18 [nikos]
https://github.com/w3c/svgwg/issues/293
20:46:33 [nikos]
AmeliaBR: Nikos posted a new comment, which I haven't read yet
20:46:38 [nikos]
nikos: I hope it's correct (ish)
20:46:54 [nikos]
AmeliaBR: I agree with your thinking that we should consider patternContentUnits as a special automatic viewBox
20:47:03 [nikos]
... so think of content coordiante system the way we do with viewBox
20:47:23 [nikos]
... 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 [nikos]
... if we're being consistent iwth patternTransform, it would apply in the pattern tile coordinate system
20:48:02 [nikos]
... 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 [nikos]
... assuming that's obb for patternUnits
20:48:19 [nikos]
nikos: Yeah that's the way I understood it as well
20:48:42 [nikos]
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 [nikos]
... not sure where in the sequence of transforms that would work most logically
20:49:10 [nikos]
I think most of the browsers are consistent when patternUnits is userSpaceOnUse
20:49:20 [nikos]
... so if we double check what they'r edoing there and make sure it all makes sense
20:50:01 [nikos]
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 [nikos]
Tav: sounds like a good idea to me
20:50:16 [nikos]
... please make tests work in Inkscape
20:51:36 [nikos]
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]
nikos: Next question if who will make tests
20:52:20 [nikos]
AmeliaBR: Would be good to look at what existed in 1.1 and why was this falling through
20:52:41 [nikos]
nikos: I'll look at what was there and convert those options
20:53:20 [nikos]
... 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 [nikos]
Topic: Testing - anti aliasing issues
20:54:45 [nikos]
https://github.com/w3c/web-platform-tests/pull/4015/
20:55:02 [nikos]
In this PR there's some tests where the SVG test and the SVG reference have some subtle anti aliasing differences
20:55:17 [nikos]
... this is caused by the numerous levels of transform that the graphics in the test go through
20:55:48 [nikos]
... 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 [nikos]
... but doing that is really hard, and it's not really scalable
20:56:32 [nikos]
... it's going to be an ongoing problem
20:56:43 [nikos]
AmeliaBR: due to the nature of the different graphics that we are use to test and reference
20:56:54 [nikos]
... I don't really have any suggestions or resolutions at the moment
20:57:03 [nikos]
... when I ran the tests through webkit they did fail
20:57:16 [nikos]
... webkit test runner reported 0.1% pixel difference
20:57:53 [nikos]
Tav: How did you run the tests?
20:58:00 [nikos]
nikos: Through the webkit test infrastructue
20:58:18 [nikos]
... you need a checkout of webkit, you build it, then you use ./Tools/scripts/run-webkit-tests
20:58:22 [nikos]
... and specify your tests
20:58:37 [nikos]
... for webkit references need a different name than in web-paltform-tests
20:58:51 [nikos]
... it's fairly simple if you have all the bits ready to go
20:59:01 [nikos]
AmeliaBR: InkScape currently use PNG references?
20:59:06 [nikos]
Tav: we don't have automated testing right now
20:59:19 [nikos]
... have had it in the past - the reference doesn't really matter
20:59:23 [nikos]
... can be svg or png
20:59:50 [nikos]
... what I would do for the amount of tests we have is to go through them visually
21:00:20 [nikos]
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]
nikos: So my plan is to do some investigation about how browsers handle little differences
21:01:15 [nikos]
... and talk to heycam and see if he has thoughts on the matter
21:01:37 [nikos]
AmeliaBR: I looked at wpt - most are script tests, but some canvas tests are ref tests
21:01:44 [nikos]
... those ref tests replace canvas element with a png
21:02:01 [nikos]
... assume the png was generated from the canvas - it must have come up at some point before
21:03:04 [nikos]
Tav: can you set the threshold?
21:03:18 [nikos]
nikos: You can at the project level, not sure for individual tests
21:03:25 [nikos]
AmeliaBR: threshold is an icky way to do things
21:04:23 [nikos]
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 [nikos]
Tav: SVG spec is only accurate to 0.5 px anyway
21:05:13 [nikos]
AmeliaBR: it might be worth specifically pinging people from other implementations about how internal tools handle subtle differences
21:05:21 [nikos]
... only other option is to go with png reference
21:05:27 [nikos]
... which is more reliable for any given implementation
21:05:40 [nikos]
... but there'll be more differences from one implementation to the next
21:05:46 [nikos]
nikos: And one platform to the next even
21:06:28 [nikos]
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 [nikos]
RRSAgent, make minutes
21:07:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/11/24-svg-minutes.html nikos
21:20:19 [stakagi]
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 [AmeliaBR]
Have you had a chance to look into it stakagi? Can you make a GitHub issue?
21:27:14 [stakagi]
roger that.