SVG Working Group Teleconference -- 26 Sep 2013

<trackbot> Date: 26 September 2013

<scribe> scribeNick: cyril

<scribe> scribe: Cyril

krit1: are we enough people to make decisions

ed: I think so

modes of SVG in SVG Integration

<krit1> https://svgwg.org/specs/integration/

krit1: the spec has different modes
... referencing modes for SVG
... do we need all of them ?
... only 2 seem relevant
... referencing for gradients, patterns
... for me the integration is more for security model and for how to use svg
... but doug would disagree with me
... we could have 2 modes: document mode and resource mode
... and have use cases
... we don't want to retrict browsers to activate/deactive scripts
... I have nothing against describing modes that can be used
... but not specifiying them

ed: we should describe how browsers behave wrt loading of resources
... are you suggesting to add that to SVG integration spec or SVG 2

krit1: integration
... we should have Doug to get an agreement

ed: have you discussed it?

krit1: we have an agreement that heycam and me would be editors
... but I'd like to have an agreement on the direction

ed: discussion postponed until doug is present

scaling dash patterns and strokes

ThomasSmailus: I think there is a need for having stroke patterns that don't change when the scale factor applies
... the pattern should stay the same
... currently if yo uzoom in or out the pattern changes

Tav: I could see several behaviors
... the stroke stays the same
... the pattern stays the same

nikos: do you want the whole pattern to be rendered in screen space

ThomasSmailus: yes
... eg on a rail road map, if you zoom on it, the pattern should stay the same

Tav: I would think that vector effect with non scaling stroke should do that

ThomasSmailus: that does no't seem to be the case in the example

<ed> http://jsfiddle.net/akvzh/4/

Tav: it's weird when you scale up the pattenr gets smaller
... is there a case where the stroke would change width but the dash pattern stays fixed
... if not we specify that if the width is not changing then the dash pattern should not change
... we should make it clearer in the spec

krit1: that's not what browsers or Adobe Illustrator does

Tav: that does not make sense to me how it behaves now

krit1: if you zoom the width may not change but the length and the dash array changes

ThomasSmailus: I guess I would want a non scaling dash pattern

nikos: that would apply to hatches I think too

ThomasSmailus: yes you can see hatches as a 2D dash array

nikos: from what I've been told, PDF is also trying to fix that but it's not easy

<nikos> WebCGM and CGM supports this

krit1: some computations are not easy, Illustrator is doing the same thing as browsers by accident because the current libraries don't offer the right tools for that

ed: how do we proceed, add a new property ?

krit1: I think it's an implementation issue

nikos: I would need to see how it behaves

Tav: it's a very important property

nikos: agreed

ed: does someone wants to investigate more

krit1: it's enough to implement with Canvas, browsers don't add more magic
... thomas do you have resources for that

ThomasSmailus: not at the moment

Tav: I could try and implement it in Inkscape but not the in a month

Issue: investigate possible implementation issues around dash array patterns

<trackbot> Error creating an ISSUE: an internal error occurred. Please mail <sysreq@w3.org> with details about what happened.

ThomasSmailus: CGM has support for that

nikos: and WebCGM too

<nikos> http://www.w3.org/Graphics/WebCGM/

ThomasSmailus: if we figure out how they do it
... that would give us an implementation
... but is it just an implementation aspect or does it need to be specified differentyl

nikos: can you specify a different coordinate space when you specify a hatch or pattern
... would using 'screen' be enough ?

cyril: looks like constrained transform

krit1: that's a different topic
... it would be possible for patterns but for lines it's different

nikos: I think patterns are the important case

ThomasSmailus: for me the more important case is dashed lines

krit1: parsers don't have control over the dash array
... you could solve it by transforming the path into the right coordinate space
... need to think about it

<ed> ISSUE-2451?

<trackbot> ISSUE-2451 -- Investigate implementability of non-scaling dash array patterns -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2451

ed: postponed until someone has the time investigate further

hit testing svg root

ed: doug is not here

location and dates for 2014 Q1 F2F

cyril: Sydney !

krit1: CSS is meeting January 27-29 in Seattle

<ed> http://doodle.com/kzd7fuw48t6ds4fn

nikos: fine with me
... or we can hot if you want to come to Syndey

krit1: do we have a schedule for the whole year ?
... it's better for the budget

ed: next one is TPAC
... then february
... most people suggest 3 or 4 meeting per year

3 or 4 days each

cyril: I can host in Paris if you want

Tav: nice to be in a reasonable time zone

ed: would be fine in Seattle if it is next to the CSS meeting

<richardschwerdtfeger> +1

ed: 3 days of meeting between 29 and 31st

krit1: I will discuss it in the CSS WG

RESOLUTION: SVG WG will meet in Seattle between the 29 and the 31st of January 2014

suggestions for other meetings ?

ed: suggestions for other meetings ?
... we have several companies willing to host
... Hachette offered to host too

nikos: Canon can host in Tokyo if we want to go there again

cyril: we need to look at the dates of the Libre Graphics and/or The Graphical Web

<scribe> ACTION: ed to discuss with heycam and send suggestion dates or questionnaire for the next few meetings in 2014 [recorded in http://www.w3.org/2013/09/26-svg-minutes.html#action01]

<trackbot> Created ACTION-3531 - Discuss with heycam and send suggestion dates or questionnaire for the next few meetings in 2014 [on Erik Dahlström - due 2013-10-03].

ed: reminder the daylight saving time shift will happen soon

<ed> http://www.timeanddate.com/time/dst/2013b.html

ed: please check your emails and use the link
... we will change after TPAC

krit1: Chris says he is fine with meetings in the evening but before 10pm

cyril: we could look at scheduling the meetings in the evening in West coast, afternoon in Australia, and morning in Europe
... the only problem is East Coast
... don't know if for who it would be a problem

Tav: we have to pick a time for Japan

<scribe> ACTION: ed to create a questionnaire to setup the new telcon time [recorded in http://www.w3.org/2013/09/26-svg-minutes.html#action02]

<trackbot> Created ACTION-3532 - Create a questionnaire to setup the new telcon time [on Erik Dahlström - due 2013-10-03].

nikos: weighted questionnaire to favor people who suffered in the past

krit1: will have agenda items on filters next week

CSS new API for shapes

krit1: it might be of interest to the group

cyril: do you have a link to a WD

krit1: no, soon DOM Matrix and CSS OM view will be merged
... the geometry APIs of them
... I would like the members to look at them and comment if possible on www-style

<krit1> http://dev.w3.org/csswg/cssom-view/#the-domrect-and-domrectimmutable-interfaces

krit1: the only problem I see so far is that CSS uses top/left ... and we would need x and y
... I'm not sure what is the best solution
... we might discuss that at TPAC

ed: all browsers have to deal with x,y anyway and not onyl topleft
... I don't think that's such a big problem
... but we should raise the issue

- DRAFT -

SVG Working Group Teleconference

26 Sep 2013

Attendees

Contents

modes of SVG in SVG Integration

scaling dash patterns and strokes

hit testing svg root

location and dates for 2014 Q1 F2F

CSS new API for shapes

Summary of Action Items

Scribe.perl diagnostic output