Minutes, 24 November 2016 SVG WG telcon

https://www.w3.org/2016/11/24-svg-minutes.html


W3C- http://www.w3.org/

- DRAFT -
SVG Working Group Teleconference

24 Nov 2016

Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0017.html
IRC log: http://www.w3.org/2016/11/24-svg-irc

Attendees
   Present
          nikos, AmeliaBR, Tav, stakagi

   Regrets
  Thomas
   Chair
          Nikos

   Scribe
          nikos

Contents

     * [4]Topics
         1. [5]Workflow for SVG 2 CR changes
         2. [6]patternTransform browser implementations do not
            match spec
         3. [7]Testing - anti aliasing issues
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   [10]https://lists.w3.org/Archives/Public/public-media-capture/2
   016Nov/0054.html

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

   <scribe> Scribe: nikos

Workflow for SVG 2 CR changes

   [11]https://github.com/w3c/svgwg/wiki/Guidelines-for-updating-S
   VG-2-CR

     [11] 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

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

     [12] 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

   [13]https://github.com/w3c/svgwg/pull/296

     [13] 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

   [14]https://github.com/w3c/svgwg/issues/293

     [14] 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

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

     [15] 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

Summary of Action Items

Summary of Resolutions

    1. [16]pattern transforms are intended to work as described in
       SVG 1.1 (though clarification of some cases is required) -
       browser behaviour is wrong

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 24 November 2016 23:48:36 UTC