https://lists.w3.org/Archives/Public/public-media-capture/2016Nov/0054.html

<scribe> Scribe: nikos

Workflow for SVG 2 CR changes

https://github.com/w3c/svgwg/wiki/Guidelines-for-updating-SVG-2-CR

nikos: earlier in the week I posted a link to this wiki
... it just lays out the procedure for updating the SVG 2 CR

https://svgwg.org/svg2-draft/changes.html#structure

nikos: If you look just above that anchor, you'll see one I did earlier in the week
... happy to adjust the formatting
... Here's a PR I created earlier as an example

https://github.com/w3c/svgwg/pull/296

nikos: If you're happy that the PR is ok, checking against the review guidelines, then you can just go ahead and merge
... I would be happy for the person who merges to delete the branch - you can always restore and submitter has a copy

patternTransform browser implementations do not match spec

https://github.com/w3c/svgwg/issues/293

AmeliaBR: Nikos posted a new comment, which I haven't read yet

nikos: I hope it's correct (ish)

AmeliaBR: I agree with your thinking that we should consider patternContentUnits as a special automatic viewBox
... so think of content coordiante system the way we do with viewBox
... 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
... if we're being consistent iwth patternTransform, it would apply in the pattern tile coordinate system
... the other part that is fairly clearly defined is that the transform is supposed to apply after you convert to objectBoundingBox if neccessary
... assuming that's obb for patternUnits

nikos: Yeah that's the way I understood it as well

AmeliaBR: I'd have to sit down and work it out - for patterns there's also the translation effect of actually tiling
... not sure where in the sequence of transforms that would work most logically

I think most of the browsers are consistent when patternUnits is userSpaceOnUse

scribe: so if we double check what they'r edoing there and make sure it all makes sense

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

Tav: sounds like a good idea to me
... please make tests work in Inkscape

RESOLUTION: pattern transforms are intended to work as described in SVG 1.1 (though clarification of some cases is required) - browser behaviour is wrong

nikos: Next question if who will make tests

AmeliaBR: Would be good to look at what existed in 1.1 and why was this falling through

nikos: I'll look at what was there and convert those options
... 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

Testing - anti aliasing issues

https://github.com/w3c/web-platform-tests/pull/4015/

In this PR there's some tests where the SVG test and the SVG reference have some subtle anti aliasing differences

scribe: this is caused by the numerous levels of transform that the graphics in the test go through
... 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
... but doing that is really hard, and it's not really scalable
... it's going to be an ongoing problem

AmeliaBR: due to the nature of the different graphics that we are use to test and reference
... I don't really have any suggestions or resolutions at the moment
... when I ran the tests through webkit they did fail
... webkit test runner reported 0.1% pixel difference

Tav: How did you run the tests?

nikos: Through the webkit test infrastructue
... you need a checkout of webkit, you build it, then you use ./Tools/scripts/run-webkit-tests
... and specify your tests
... for webkit references need a different name than in web-paltform-tests
... it's fairly simple if you have all the bits ready to go

AmeliaBR: InkScape currently use PNG references?

Tav: we don't have automated testing right now
... have had it in the past - the reference doesn't really matter
... can be svg or png
... what I would do for the amount of tests we have is to go through them visually

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

nikos: So my plan is to do some investigation about how browsers handle little differences
... and talk to heycam and see if he has thoughts on the matter

AmeliaBR: I looked at wpt - most are script tests, but some canvas tests are ref tests
... those ref tests replace canvas element with a png
... assume the png was generated from the canvas - it must have come up at some point before

Tav: can you set the threshold?

nikos: You can at the project level, not sure for individual tests

AmeliaBR: threshold is an icky way to do things

nikos: one sugggestion I got from someone at work is to convert output to 1bpp and ignore 1 pixel around the boundary

Tav: SVG spec is only accurate to 0.5 px anyway

AmeliaBR: it might be worth specifically pinging people from other implementations about how internal tools handle subtle differences
... only other option is to go with png reference
... which is more reliable for any given implementation
... but there'll be more differences from one implementation to the next

nikos: And one platform to the next even
... I'll keep chugging along with this, but there's plenty of other tests we can convert that won't exhibit the problem

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: nikos
Inferring ScribeNick: nikos
Present: nikos AmeliaBR Tav stakagi
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0017.html
Found Date: 24 Nov 2016
Guessing minutes URL: http://www.w3.org/2016/11/24-svg-minutes.html
People with action items: