- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Thu, 26 Sep 2013 23:17:58 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
Hi all,
Here are the minutes:
http://www.w3.org/2013/09/26-svg-minutes.html
and as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
26 Sep 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-svg/2013Sep/0040.html
See also: [3]IRC log
[3] http://www.w3.org/2013/09/26-svg-irc
Attendees
Present
Regrets
heycam, brian, luc, chris
Chair
ed
Scribe
Cyril
Contents
* [4]Topics
1. [5]modes of SVG in SVG Integration
2. [6]scaling dash patterns and strokes
3. [7]hit testing svg root
4. [8]location and dates for 2014 Q1 F2F
5. [9]CSS new API for shapes
* [10]Summary of Action Items
__________________________________________________________
<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> [11]https://svgwg.org/specs/integration/
[11] 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> [12]http://jsfiddle.net/akvzh/4/
[12] 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> [13]http://www.w3.org/Graphics/WebCGM/
[13] 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>
[14]http://www.w3.org/Graphics/SVG/WG/track/issues/2451
[14] 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> [15]http://doodle.com/kzd7fuw48t6ds4fn
[15] 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
[16]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> [17]http://www.timeanddate.com/time/dst/2013b.html
[17] 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
[18]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>
[19]http://dev.w3.org/csswg/cssom-view/#the-domrect-and-domrect
immutable-interfaces
[19] 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
Summary of Action Items
[NEW] ACTION: ed to create a questionnaire to setup the new
telcon time [recorded in
[20]http://www.w3.org/2013/09/26-svg-minutes.html#action02]
[NEW] ACTION: ed to discuss with heycam and send suggestion
dates or questionnaire for the next few meetings in 2014
[recorded in
[21]http://www.w3.org/2013/09/26-svg-minutes.html#action01]
[End of minutes]
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/
Received on Thursday, 26 September 2013 21:18:42 UTC