Minutes F2F Pyrmont, Sydney day 1 (04/01/2013)

The minutes before midnight are here:
http://www.w3.org/2013/02/03-svg-irc.txt
after midnight are here:
http://www.w3.org/2013/02/04-svg-minutes.html

and the text version below:

22:34:00 <RRSAgent> RRSAgent has joined #svg
22:34:00 <RRSAgent> logging to http://www.w3.org/2013/02/03-svg-irc
22:34:02 <trackbot> RRSAgent, make logs public
22:34:02 <Zakim> Zakim has joined #svg
22:34:04 <trackbot> Zakim, this will be GA_SVGWG
22:34:04 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:34:05 <trackbot> Meeting: SVG Working Group Teleconference
22:34:05 <trackbot> Date: 03 February 2013
22:34:14 <heycam> Meeting: SVG F2F Sydney 2013 Day 1
22:34:18 <heycam> Chair: Cameron
22:34:46 <nikos> nikos has joined #svg
22:44:13 <jun> jun has joined #svg
22:52:36 <shanestephens_> krit: http://en.wikipedia.org/wiki/Rube_Goldberg_machine
22:54:07 <Cyril_> Cyril_ has joined #svg
22:59:48 <nikos> nikos has joined #svg
23:02:57 <birtles> scribenick: birtles
23:05:14 <birtles> topic: SVG2 status
23:06:45 <birtles> heycam: I'd like to know what features we want to get in the spec soon if we publish soon
23:06:59 <birtles> ... and whether it's achievable to get done all the things we've signed up for
23:07:07 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
23:07:11 <birtles> ... there are still a few things in the requirements commitments page that are yet to be done
23:07:40 <stakagi> stakagi has joined #svg
23:07:44 <birtles> ... green ticks indicate that something has actually been added to the spec
23:07:48 <birtles> ... but I'm not sure it's quite up to date
23:08:01 <birtles> ... things which don't have anyone signed up for, perhaps we can assume they won't be in SVG2
23:08:14 <birtles> Cyril: can we quickly review them?
23:08:33 <birtles> heycam: yes, of course
23:11:17 <birtles> [1] Add a section to the Requirements document about general approaches including avoiding backwards compatible changes
23:11:30 <birtles> heycam: just busy work?
23:11:38 <birtles> Cyril: maybe add a section to changes section
23:12:06 <birtles> ... highlight which changes are backwards compatible and which are not
23:12:40 <birtles> ACTION: Cameron to add a sentence to the changes section regarding requirement one (about requirements)
23:12:41 <trackbot> Created ACTION-3411 - Add a sentence to the changes section regarding requirement one (about requirements) [on Cameron McCormack - due 2013-02-10].
23:12:46 <birtles> [2] Keep accessibility in mind when designing new features, and improve existing features where we can
23:12:51 <AlexD> AlexD has joined #svg
23:12:56 <birtles> all: ok, we will bear that in mind
23:13:00 <birtles> [3] Support the z-index
23:13:49 <birtles> heycam: it's assigned to Tab
23:14:03 <birtles> ... but jwatt has done some work on the spec text
23:14:06 <birtles> ... let's keep that
23:14:14 <birtles> [4] Ensure there is a way to avoid getting seams on adjacent edges of rendered elements
23:14:45 <birtles> birtles: is that shared path functionality?
23:14:50 <birtles> heycam: it's more than just that
23:15:30 <birtles> Cyril: it means you have to render at the same time
23:15:36 <birtles> AlexD: only if you have anti-aliasing
23:16:13 <birtles> Cyril: super path is one thing, but it doesn't help for, e.g., two rectangles
23:16:43 <birtles> ... it would be good clarify in SVG2
23:16:51 <birtles> heycam: unless someone volunteers to do it...
23:16:59 <birtles> krit: I think we should move fast on SVG2
23:17:04 <birtles> heycam: we should try to cut stuff
23:17:23 <birtles> heycam: no concrete plan, no owner...
23:17:52 <birtles> AlexD: it also puts requirements on graphics libraries
23:18:04 <birtles> ... it's a lot of work too
23:18:10 <birtles> ... it's too big for SVG2
23:18:22 <birtles> all: skip for SVG2
23:18:23 <birtles> [5] Support flattening vector graphics to image
23:19:13 <birtles> krit: last time Cyril proposed it, one of the issues was whether the flattened graphic is scalable or not
23:19:21 <birtles> Cyril: I think there are two possibilities
23:19:27 <birtles> ... the suggestion here is just keeping the pixels
23:19:33 <birtles> ... not the graphics tree
23:19:57 <birtles> krit: do we want a property that forces creation of a buffer in the GPU?
23:20:15 <birtles> ... I think this is needed--the property to indicate you want a new layer or not
23:21:01 <birtles> birtles: we have a discussion about this on the agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/Performances_to_transition_in_zooming_and_panning
23:21:20 <birtles> heycam: ok, let's revisit it then
23:21:28 <birtles> [6] Clean up the namespace requirements
23:22:43 <birtles> it's about removing the need for namespace prefixes (xml:lang, xml:base, xml:id)
23:22:53 <birtles> heycam: I think we want to make those changes
23:23:40 <birtles> ACTION: Cyril to fix spec to remove need for xml namespace prefix
23:23:40 <trackbot> Created ACTION-3412 - Fix spec to remove need for xml namespace prefix [on Cyril Concolato - due 2013-02-10].
23:24:44 <heycam> ACTION-3412: See also http://www.w3.org/mid/50D5B322.70308@mcc.id.au
23:24:44 <trackbot> Notes added to ACTION-3412 Fix spec to remove need for xml namespace prefix.
23:24:51 <birtles> [7] Clean up the use element section (in terms of Shadow DOM).
23:25:23 <birtles> heycam: would be nice, what is status of shadow DOM spec?
23:25:29 <birtles> AlexD: seems to be getting stable
23:25:36 <shepazu> (I've done a little work on this one)
23:25:47 <birtles> heycam: we should try to address this soon so we can give feedback to shadow dom guys
23:26:11 <birtles> AlexD: it's used within WebKit
23:27:10 <shepazu> (I don't mind if someone else takes this action over)
23:27:15 <birtles> shanestephens_: the way use works and shadow dom works have some differences
23:27:23 <birtles> ... there may be issues there
23:27:24 <heycam> shepazu, do you have a link? or can you send it to the list?
23:27:48 <birtles> heycam: I think the instance tree (which half the implementations don't support) and the way inheritance works are two odd areas
23:28:07 <shepazu> heycam, no concrete work, just reading, talking with Dmitri, and understanding the model
23:28:29 <birtles> krit: I think we should delay this action since it is a bigger item
23:28:46 <birtles> birtles: what should we do about the instance tree since half the implementations don't support it?
23:28:54 <birtles> krit: can we mark it as likely to change?
23:29:25 <birtles> ... or drop it?
23:32:12 <birtles> heycam: it might still be good to look into this
23:32:21 <birtles> ... to see if we *could* do use in terms of the shadow dom
23:32:33 <birtles> ... in case we want to do that in a subsequent version
23:33:06 <birtles> ACTION: Cyril to investigate describing use in terms of the shadow DOM
23:33:07 <trackbot> Created ACTION-3413 - Investigate describing use in terms of the shadow DOM [on Cyril Concolato - due 2013-02-10].
23:33:24 <shepazu> (my discussions with Dmitri and Tab didn't reveal any show stoppers)
23:33:34 <heycam> shepazu, good to know
23:33:34 <birtles> heycam: but in terms of requirements for SVG2, we will say, "not for now"
23:33:40 <birtles> [8] Clean up the shadow tree section
23:34:21 <birtles> heycam: also, Cyril, please consider if we need the instance tree or not
23:35:48 <birtles> [9] Clean up the marker section
23:36:23 <birtles> heycam: mostly done except for knocking out parts of the stroke
23:36:28 <birtles> ... we'll talk about that later in the week
23:36:35 <birtles> ... the rest should be fine
23:36:50 <birtles> [10] Improve the DOM
23:36:59 <Cyril> http://www.w3.org/mid/4DC17F7F.6060708@w3.org
23:38:09 <birtles> Cyril: we have already fixed a number of small items like fixing lists
23:38:17 <birtles> ed: we also talked about pointing to the CSSOM
23:38:26 <birtles> ... e.g. for CSSLength, but it's not ready
23:39:39 <birtles> shanestephens_: CSSOM is progressing slowly
23:39:47 <birtles> heycam: we should have a separate discussion for this later
23:40:33 <birtles> (added to agenda)



   

W3C <http://www.w3.org/>


  - DRAFT -


  SV_MEETING_TITLE


    04 Feb 2013


    Attendees

Present
Regrets
Chair
    Mighty Cameron
Scribe
    Cyril


    Contents

  * Topics <http://www.w3.org/2013/02/04-svg-minutes.html#agenda>
     1. Marker knockouts using masking or compositing
        <http://www.w3.org/2013/02/04-svg-minutes.html#item01>
     2. Canvas path proposal
        <http://www.w3.org/2013/02/04-svg-minutes.html#item02>
     3. SVG DOM path improvements
        <http://www.w3.org/2013/02/04-svg-minutes.html#item03>
     4. prioritization of remaining requirements
        <http://www.w3.org/2013/02/04-svg-minutes.html#item04>
  * Summary of Action Items
    <http://www.w3.org/2013/02/04-svg-minutes.html#ActionSummary>

------------------------------------------------------------------------

<birtles> [11] Expose animateMotion values in the SVG DOM

<birtles> birtles: is it not exposed in the animated value of the 
transformed list?

<birtles> all: no it's not

<birtles> krit: shouldn't it be exposed through the OM for CSS Transforms?

<birtles> shanestephens_: it would be better if you can query the 
animated value per animation effect not just the composite result

<birtles> heycam: yeah, that would be nice

<birtles> shanestephens_: we can add an API for that in Web Animations

<birtles> heycam: let's leave it to Web Animations then

<birtles> krit: what about adding a new layer/stylesheet for animation 
to the cascade?

<birtles> ... it would need to be defined by Web Animations

<birtles> heycam: let's drop it from the requirements list and leave it 
to Web Animations

<birtles> [12] Make the SVG*List interfaces a bit more like other 
lists/arrays

<birtles> ed: I think heycam did it

<birtles> heycam: I think I did it when I converted the interfaces to 
Web IDL

<birtles> ... I guess it's done

<birtles> [13] Make it easier to read and write to attributes in the SVG DOM

<birtles> AlexD: I think the proposal for rect.x.px is nice for developers

<birtles> heycam: it would be pretty easy to add just that

<birtles> ... so should we just do that?

<birtles> all: seems good

<birtles> heycam: should it be base val or a hybrid of anim/base val?

<birtles> all: seems better to just use base val

<birtles> *ACTION:* Cameron to add length shortcuts to SVG DOM [recorded 
in http://www.w3.org/2013/02/04-svg-minutes.html#action01]

<trackbot> Created ACTION-3414 - Add length shortcuts to SVG DOM [on 
Cameron McCormack - due 2013-02-11].

<birtles> heycam: how would you represent calc() etc. in the DOM?

<birtles> ... do you just have to use the CSSOM for that?

<birtles> krit: let's talk about that as part of the CSSOM discussion

<birtles> [14] Improve the SVG path DOM APIs

<heycam> 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements

<birtles> birtles: I made a proposal about creating paths from an array 
of floats

<birtles> ... it would also be neat to have some constructors for some 
of the path data types

<birtles> heycam: what about extending the existing methods but allowing 
them to take a string instead

<birtles> ... let's keep the requirement for now

<birtles> ... we'll go into it when we talk about canvas path proposal later

<birtles> [15] Ensure improved property value access to SVG properties

<birtles> ... CSSOM will fix this, skip it

<birtles> [16] Improve bounding box method APIs

<birtles> [We think we have already added this to the spec, but there is 
some discussion related to this later in the week.]

<birtles> ... keep it

<birtles> [17] Have a method for <image> to select a part of an image to 
display, maybe by allowing viewBox on it

<birtles> AlexD: good for DOM spriting

<birtles> heycam: you can do this with media fragments

<birtles> ... do we need a separate feature for this?

<birtles> krit: does that apply to <image> elements too?

<birtles> ... we need to add spec text for that (supporting image fragments)

<birtles> ... and then we run into trouble with SVG sprites etc.

<birtles> heycam: I thought we resolved that

<birtles> krit: we only resolved that for CSS, not for SVG

<birtles> ... (i.e. CSS properties, not xlink:href)

<birtles> ... we need to define how <image> interacts with media fragments

<birtles> [Added to agenda]

<birtles> [18] Allow auto-sized images

<birtles> heycam: no progress there

<birtles> ... it's to do with adding "auto" to <image> element's width 
and height

<birtles> ... I think we decided they should default to zero

<birtles> ... but it's yet to be added to the spec

<birtles> ... the only issue remaining is just how to reflect auto in 
SVGLength

<birtles> ... we could just use UNKNOWN

<birtles> ... like we do for transforms

<birtles> krit: but then what would you do for, e.g., <rect>

<birtles> ... since it uses the same property

<birtles> ... you would have to define what it means to have a <rect> 
whose width is "auto"

<birtles> heycam: we could just make it zero (the initial value)

<birtles> ... let's keep this one

<birtles> *ACTION:* Cameron to spec auto-sized images [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action02]

<trackbot> Created ACTION-3415 - Spec auto-sized images [on Cameron 
McCormack - due 2013-02-11].

<birtles> [19] Support level of detail control

<birtles> birtles: will be covered tomorrow when we discuss <iframe> for SVG

<birtles> heycam: let's keep the requirement for now

<birtles> [20] Be able to display InkML trace groups by some means such 
as buffered-rendering and variable stroke width , not necessarily 
varying anything

<birtles> heycam: this is basically variable stroke-width

<birtles> ... which we will discuss later

<birtles> birtles: there's also buffered rendering

<birtles> heycam: which ed already added to the spec

<birtles> [21] Allow transform on the <svg> element

<birtles> ed: done right?

<birtles> krit: yes, since you added <svg> to SVGGraphicsElement

<birtles> ... but we need to specify what happens on the root element

<birtles> ... but CSS Transforms is not supposed to apply to the root 
element I think...

<birtles> heycam: but what if you apply CSS transforms to the <html> 
element?

<birtles> krit: I think that should work actually...

<birtles> heycam: I think root <svg> should do that same as <html>

<birtles> ed: I agree

<birtles> *ACTION:* Dirk to investigate applying CSS transforms to SVG 
when it is the root element of the document [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action03]

<trackbot> Created ACTION-3416 - Investigate applying CSS transforms to 
SVG when it is the root element of the document [on Dirk Schulze - due 
2013-02-11].

<birtles> heycam: we need to specify the order in which the transform 
applies in relation to the viewBox etc.

<birtles> krit: yes, we need to define where it applies

<birtles> RESOLUTION: transforms should apply at the beginning of the 
transform cascade (as if the transform applied to a group around the 
<svg> element)

<birtles> [22] Support a mechanism like or the same as allowReorder from 
SMIL3

<birtles> heycam: still needs to be done

<birtles> ... it would be an easy one to add if someone wants to do it

<birtles> ... if no one wants to add it, skip it for now

<Cyril> http://www.w3.org/Graphics/SVG/WG/track/issues/2238

<birtles> [23] Relax referencing requirements to particular elements to 
allow dropping fragments to mean referencing root element, where it 
makes sense, such as with use

<birtles> heycam: makes sense

<birtles> *ACTION:* Cameron to relax referencing requirements 
(issue-2295) [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action04]

<trackbot> Created ACTION-3417 - Relax referencing requirements 
(issue-2295) [on Cameron McCormack - due 2013-02-11].

<birtles> [24] Normatively reference the SVG Parameters spec

<birtles> heycam: we need to resolve how this interacts with CSS 
variables before we references it

<birtles> krit: so, not now?

<birtles> ... I don't think we have an editor for it now

<birtles> heycam: so let's not normatively reference it until it's ready

<birtles> [25] Add data-* attributes to align with HTML5

<birtles> heycam: I think we should do that

<birtles> ... might need coordination if it's defined on HTMLElement

<birtles> ... so we can reference it

<birtles> ... it's currently on HTMLElement

<birtles> krit: we could add it to Element

<birtles> ed: where should we add it? SVGElement or Element?

<birtles> heycam: someone should send a mail to whatwg list regarding 
moving data to Element

<birtles> *ACTION:* Cameron to mail HTML people about moving data to 
Element [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action05]

<trackbot> Created ACTION-3418 - Mail HTML people about moving data to 
Element [on Cameron McCormack - due 2013-02-11].

<birtles> [26] Align with HTML5 global semantic attributes where these 
make sense for SVG

<birtles> [this is things about microdata]

<heycam> 
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#global-attributes

<birtles> [Discussion about classList being on Element and issues around 
className]

<birtles> heycam: let's discuss the specific attributes later but keep 
the requirement for aligning with HTML here

<birtles> *ACTION:* Cameron to follow-up aligning with global HTML 
attributes in SVG [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action06]

<trackbot> Created ACTION-3419 - Follow-up aligning with global HTML 
attributes in SVG [on Cameron McCormack - due 2013-02-11].

<birtles> [27] Make property values case insensitive

<birtles> heycam: I think we should have this one

<birtles> ... this is just about presentation attributes

<birtles> ... they are currently case-sensitive but they shouldn't be

<birtles> [Discussion about camel case attribute names and the CSSOM]

<birtles> [28] Add color management subject to deciding the exact 
conformance classes required

<birtles> heycam: chris has already done a bunch of changes here

<birtles> [29] Include non-scaling stroke

<birtles> ed: it's implemented but not in the spec yet

<birtles> *ACTION:* Erik to add non-scaling stroke to SVG2 [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action07]

<trackbot> Created ACTION-3420 - Add non-scaling stroke to SVG2 [on Erik 
Dahlström - due 2013-02-11].

<birtles> [30] Include non-scaling features (non-scaling part of the 
object, and non-scaling entire object)

<birtles> birtles: we will cover this on Wed morning

<birtles> [31] Include a way to specify stroke-position

<birtles> heycam: a few years ago I presented a proposal for this

<birtles> ... do we still want this?

<birtles> [Discussion about implementation strategies]

<birtles> birtles: could we defer to SVG3?

<birtles> all: agreed to defer this requirement to SVG3

<birtles> [33] Allow more author control over positions of dashes

<birtles> [32] Specify more precisely stroke dashing

<birtles> heycam: done

<birtles> ... I added wording for this

<birtles> [33] Allow more author control over positions of dashes

<birtles> heycam: would be nice, but I can do without it

<birtles> ed: what kind of control

<birtles> heycam: e.g. stretching dash to corners etc.

<birtles> *ACTION:* Cameron to add dash control to SVG2 [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action08]

<trackbot> Created ACTION-3421 - Add dash control to SVG2 [on Cameron 
McCormack - due 2013-02-11].

<birtles> [34] Support hatching without the artefacts that patterns 
currently impose

<heycam> Tav, are you still on track to adding the hatching proposal to 
SVG 2?

<heycam> Tav, I think people here are keen for it to go in

<birtles> heycam: we'll assume Tav is taking care of this

<birtles> [35] Support custom filters

<birtles> krit: it's in Filter Effects

<birtles> heycam: we can just reference that

<birtles> [36] Align the style element with the HTML 5 style element

<birtles> heycam: I already have an action for this

<birtles> ... it's about adding scoped etc.

<birtles> AlexD: what about href?

<birtles> ... that's pretty painful

<birtles> heycam: we decided to drop xlink from href everywhere

<shepazu> (not just href... all xlink elements, like title, etc.)

<birtles> AlexD: HTML uses src and this is a real pain point for developers

<birtles> heycam: we should just use 'src' in SVG's style element too

<birtles> heycam: so we decided <image> would allow 'xlink:href', 'href' 
AND 'src'?

<birtles> [seems so, but which one wins?]

<birtles> nikos: there was some discussion at rigi about that

<birtles> heycam: details, we can work that out later

<birtles> [37] Include better bounding-box querying functions

<birtles> dupe, skip

<birtles> [38] Ensure there is a way to specify rotations around 
particular points and shapes

<birtles> heycam: this may be fixed by transform-origin?

<birtles> Dmitry: I want to rotate two elements around a point together 
(even though they may already have other rotation)

<birtles> krit: we could make transform-origin a list in the future

<birtles> Dmitry: we also need an origin for scale

<birtles> krit: we could also solve this with a list for transform-origin

<birtles> [This will be resolved in CSS Transforms]

<birtles> [39] Support shared path segments

<birtles> shanestephens_: this would be handy for animation

<birtles> cabanier: I thought we already deferred this

<birtles> *ACTION:* Cyril to specify shared-path segments [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action09]

<trackbot> Created ACTION-3422 - Specify shared-path segments [on Cyril 
Concolato - due 2013-02-11].

<birtles> [40] Include the smooth path between points functionality 
(Catmull-Rom)

<heycam> shepazu, are you still OK to be assigned to add the catmull-rom 
stuff to the spec?

<birtles> Dmitry: it's very popular amongst developers

<birtles> birtles: I think the only outstanding issue was the tension 
property

<birtles> heycam: I'd like to have it as well

<shepazu> heycam, yes, unless someone else wants to do it

<heycam> shepazu, yes no problem; we're just trying to remove things 
from the list that aren't realistically going to get done, but if it's 
still on your radar that's fine

<scribe> scribenick: nikos


      Marker knockouts using masking or compositing

heycam: I put some half baked proposal into the spec for clipping that 
takes away part of the stroke so markers can have a hollow section, or a 
boundary around the edge
... I think what I specced might be difficult to use

<Cyril> https://svgwg.org/svg2-draft/painting.html#MarkerKnockout

heycam: I did it that way to avoid having to do some path geometry 
opertations
... I think a simpler way to do this would be with masking or compositing

cabanier: I think you'll have to special case it for compositing. The 
shape and the stroke will have to be treated as in a group

krit: Are you talking about the markers causing the knockout?

heycam: Subway station circle is a common use case

heycam draws an example on the whiteboard

<marker .... >

<path knockout />

<path ....>

heycam: I want to specify regions that knock out and regions that don't
... I want to knock out the center of the subway station circle

nikos: that's not how knock-out works

dmitry: the marker could have different masking capabilities, allowing 
you for example to apply a gradient as a mask

krit: I'd have two types of marker - a mask marker and a rendering marker

heycam: I'd like it to be part of the one if possible

Cameron writes another example

<marker marker-mask="url(#a)">

<path />

<g id="a">

heycam: Ideally we want to keep the mask group and the path together
... Does everyone think it's better to do this with masking than 
anything else?

Cyril: We have been trying to remove the use of ids, so following that 
it's better to have the mask as a child

heycam: How about a marker-mask element that is a child of the marker

shanestephens_: Having it apply to the first thing up the ancestor chain 
that is relevant makes sense

krit: So you'd always have to have a marker if you want to have a gap?

heycam: You could leave it blank
... I don't think we should use the name mask for the element, because 
it would require a special case of the way a mask applies to it's parent

heycam draws another example

<shanestephens_> marka mask: 
http://www.genuineafrica.com/images/Marka/African-Masks/African-Masks-Marka-Mask-32-F.jpg

<marker ...><markermask><circle ... r="20" /></markermask><circle ... 
r="10"/></marker><path d="..." marker-mid="url(#a")

krit: I think it would be a common use to mask without wanting to draw 
anything
... it would require a lot of mark-up to do that

heycam: I was originally thinking clipping, but using that wouldn't you 
have to do a lot of computation?

AlexD: clip-out is a common operation and is fairly simple

heycam: If there were two types of marker - drawing and masking, 
everytime you want to use that pair you have to include two references

krit: it would be good to set the order of the two types, first the 
drawing, then the clipping for example

heycam: The marker mask applies to the path though, so you want to apply 
all the masks then render the markers

dmitry: That's the way I'd expect it to work - the marker mask applies 
to the path and not to the previously drawn markers

Cyril: I think we need to consider what all the use cases are, we have 
only considered the subway station so far

heycam: I think this would allow an author to do the other things I have 
in the spec currently
... one issue I noted in the spec was that if the path is curving where 
you want to knock-out, you may want to distort the shape of the knock-out
... another question, is whether it would apply to the stroke and the 
fill, or just the stroke?

AlexD: I'd say both

cabanier: Just the stroke

heycam: I could see cases for both

Cyril: the marker position is affected by stroke-position right?

heycam: That's a good question

ed: if you change the drawing order with paint-order, do you still want 
to knock out parts that are drawn after the markers?

Cyril: The marker mask should mask anything to the left of the marker

heycam: I think that's the only way that makes sense
... I like this solution, I think it's far simpler for an author than 
what is in the spec currently

krit: what happens if the marker mask is after the marker graphic element?
... would the mask affect the marker?

heycam: no

Cyril: if two markers are close, the markers aren't affected by the 
masks are they?

heycam: No, only the stroke is affected

krit: I'm not sure about this, you would need to check every mask 
element to create the mask, it sounds complicated and error prone

heycam: I think you have to do all the masking first, you can do it per 
marker

krit: You can when you have the marker and the mask separately. Then you 
don't need to access the DOM twice

heycam: Is it because marker-mask is a child of the marker that it's 
difficult?

krit: Yes, because you have two different rendering contexts. One for each

cabanier: How do you combine the masks?

heycam: you just combine them all and draw as one

krit: If you had gradients in the mask?

heycam: You would have to composite them together

Cyril: If you had two overlapping markers and each had a left to right 
gradient. The middle would be lighter

heycam: You could specify blend modes and compositing operators on the 
marker-mask to define how they combine

krit: is marker-mask an alpha or a luminance mask? Can you specify one 
or the other?

heycam: good question, not sure
... I'm not sure it would be hard to implement. I could try writing 
something up and send it to the list?
... Can you do this masking in hardware?

krit: The biggest problem will be the position calculation of the markers

dmitry: if you replace masking with clipping does it make it easier?

heycam: I don't think so

shanestephens_: don't you need to traverse the paths anyway to place the 
markers?

krit: yes, so it doesn't make any difference whether you use clipping or 
masking

heycam: I'll write some examples and some text and we can decide later

<scribe> *ACTION:* heycam to write up examples and text for marker-mask 
[recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action10]

<trackbot> Created ACTION-3423 - Write up examples and text for 
marker-mask [on Cameron McCormack - due 2013-02-11].

<cabanier> 
http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/


      Canvas path proposal

cabanier: The canvas spec proposes to allow for a path object to be 
constructed with SVG path syntax
... and you can combine, stroke, fill, with different winding rules
... it would be good to get the modified path data back out
... Google has implemented some of this

Cyril: is it really interoperable? I think in Inkscape, for example, 
they create an approximation of the path

cabanier: how is the quality of what is produced? If you have

s/cabanier: how is the quality of what is produced? If you have 
/cabanier: how is the quality of what is produced?

krit: it can be done by the GPU. But you can't get the path data back out

cabanier: If you draw using JavaScript and perform operations like a 
union, you can't get the path data from that

heycam: So this is in the spec already? Things like arc and path

krit: Some are

cabanier: The canvas spec has some problems with strokes interacting 
with itself

heycam: I'd like to solve the problem of multiple strokes on the one 
element without using vector effects. Like using lists on the element

Cyril: Vector effects elements seems to give a way of creating the paths 
that you can build up with Rik's proposal

heycam: With the proposal, can you inspect the path data?

cabanier: No, you can only draw it

Cyril: To me, there are a lot of similarities between this proposal and 
vector effects and they should be aligned

cabanier: The path just contains segments. It's quite dumb.
... shape contains the final result that you see on the screen. But you 
can still scale it and maintain quality
... The internal representation is completely different to what you 
input, so you cannot get the data back out

krit draws an example on the whiteboard that shows how 2 drawing 
operations result in a union of the two

cabanier: And you can specify winding rules that affect the geometry 
that is created
... In the final example you draw two circles, then you union them, then 
you stroke it

heycam: Can you put markers on it?

cabanier: The markers would be on the resultant paths created

krit: How would you perform the stroking when the path is required to 
stroke?

cabanier: The path is available internally in some form, it's just not 
exposed in the script

krit: If you can get an exact match (as output) for a straight line 
polygon, then you can specify what would result from curves

heycam: I'm happy for the paths not to be exposed to script

cabanier: Then you cannot use them in SVG
... as input

krit: What outcome do we want from this discussion?

cabanier: I just wanted to make you all aware of this. Dirk and I have 
been discussing it.
... It's more of a Canvas thing, but if people think it's reasonable we 
will implement it

heycam: One way you could bring it into SVG is to set the path data as 
the output of the JavaScript

ed: would that work with scaling ?

cabanier: You would have to recalculate the path

krit: it can be a specification issue if the browser is required to be 
pixel perfect
... you could specify that pixel accuracy isn't important

Cyril: Would your proposal work with any path, e.g. Catmull-Rom?

cabanier: yes

heycam: I like the proposal

Cyril: Would the paths created by this proposal be useful for CSS 
exclusions or anything like that?

cabanier: JavaScript is required though

Cyril: It would be nice if there was a declarative equivalent
... one of the advantages of having it as declarative in SVG would be 
that you could use it for CSS exclusions

heycam: Is it worth thinking about a non declarative way of getting the 
data into SVG?
... If you could just set the JavaScript object on your path element
... You don't want to allow the path data to be output. You want a way 
to refer to constructed path

Cyril: it's like what I was requesting before. A scalable representation 
without the full DOM.

cabanier: It could be a new way of drawing. Where you draw into an object.

heycam: When you do that, would it update the d attribute?

ed: as long as the path operators are the same

cabanier: There are some differences between the defaults in some cases 
(e.g. stroking)

heycam: If this proposal gets added to the Canvas spec, then we can make 
any corresponding SVG changes

krit: if you create a path object with a CTM in the Canvas context then 
the transformations will be applied to the internal path data

Cyril: if this is accepted, we will have a mechanism for a path element 
in SVG which has no d element but the path data is set from a shape object.
... do we have a mechanism to go from a declarative path to a shape?

cabanier: You can currently input an SVG path string but the stroking, 
etc are not applied

Cyril: So I can create the shape objects, then delete all the other 
objects and just be left with the shape object with no DOM

AlexD: Yes, you have JavaScript objects instead which are even bigger 
than the DOM representations

cabanier: What we could add is to have an optimise method that returns 
another shape constructed as the intersection of the other objects.
... currently, when you call the add method, it doesn't do anything to 
the internal path data. It only adds a command to the internal 
representation

heycam: Were you thinking that this path objects and it's improvements 
would remove the need for pathSegList?
... the path object currently doesn't have a way of inspecting 
individual segments?

cabanier: no

heycam: is that something you want to add?

cabanier: I don't think there's a reason we couldn't

Cyril: what if you serialised - you want to get the SVG

cabanier: You can't serialise a Shape as you can't get the data out

heycam: So we'll wait until this progresses further with the Canvas group?

cabanier: Yes,

<scribe> *ACTION:* Rik to look at how to attach a path or shape object 
to an SVG path element [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action11]

<trackbot> Created ACTION-3424 - Look at how to attach a path or shape 
object to an SVG path element [on Rik Cabanier - due 2013-02-11].

<Cyril> scribe: Cyril


      SVG DOM path improvements

heycam: improving the SVGPathElement APIs

dirk: we resolved something in Zurich

<heycam> http://www.w3.org/2012/09/17-svg-minutes.html#item09

heycam: we have resolutions but no actions
... some of the resolutions are related to the previous discussion

<scribe> *ACTION:* Rik to edit the SVG 2 spec to add the possibility to 
set the d attribute using a Path object [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action12]

<trackbot> Created ACTION-3425 - Edit the SVG 2 spec to add the 
possibility to set the d attribute using a Path object [on Rik Cabanier 
- due 2013-02-11].

dirk: creating a new path automatically requires creating a move to 
because of underlying platform code in WebKit

heycam: the resolution from Zurich "add extendPath - which acts as 
addPath but trims off the initial moveto" is about that right?

dirk: yes
... Qt creates multiple moveTo
... sometimes, so you don't know if it's your moveTo or the one from the 
platform
... usually it doesn't matter, only if you read back

heycam: can you penalize only the Qt port ?

dirk: maybe, I don't know
... Core Graphics creates automatically a moveTo if the first is a lineTo
... everything is solvable, but how ? maybe we need to add a layer

heycam: when you're flattening you don't care about the new moveTo
... only when appending you want to preserve the original path

<scribe> *ACTION:* Rik to add the extendPath and addPath methods to the 
SVG 2 [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action13]

<trackbot> Created ACTION-3426 - Add the extendPath and addPath methods 
to the SVG 2 [on Rik Cabanier - due 2013-02-11].

heycam: the methods are on the Path object

dirk: d would not be the attribute but the path of the Path object
... how do you reflect that in the SVG DOM ?

heycam: some the segments in the Path may be different from the 
SVGPathSegList ones

<scribe> *ACTION:* Rik to add new procedural methods for catmull-rom 
[recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action14]

<trackbot> Created ACTION-3427 - Add new procedural methods for 
catmull-rom [on Rik Cabanier - due 2013-02-11].

rik: I'd like someone to add the text for Catmull Rom for the XML part, 
and I'll refer to that

heycam: yes Doug will do that
... for the resolution "add canvas-like arc commands in svg path 
syntax", Tab is working on that

ACTION-3427: waiting on the action by Doug to do the edit in the SVG syntax

<trackbot> Notes added to ACTION-3427 Add new procedural methods for 
catmull-rom.

cyril: what about the stringifier

rik: I'll do that

<scribe> *ACTION:* Rik to specify the stringifier method for the Path 
object [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action15]

<trackbot> Created ACTION-3428 - Specify the stringifier method for the 
Path object [on Rik Cabanier - due 2013-02-11].

ACTION-3428: waiting for Tab on adding the new arcs command to the SVG 
path syntax

<trackbot> Notes added to ACTION-3428 Specify the stringifier method for 
the Path object.

heycam: the next thing is Brian's proposal for taking a list of numbers 
and making a path of that

brian: you've got an interface of Path for getting an array of floats, 
one array per subpath
... but we were stuck with the close command

rik: because it does not look the same if you explicitly close it or not

brian: dealing with the array of floats is faster
... than to traverse the segment list

<birtles> http://processingjs.nihongoresources.com/bezierinfo/

brian: if no one else cares, we can just drop it
... if we think it's worthwhile we need to find a way to handle the 
close command

<birtles> previous proposal: 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Making_Improvements

<birtles> section "birtles 2012-03-26: ..."

heycam: it seems pretty simple to write

brian: yes, because it's using normalizedPathSegList

heycam: are we extending PathSegList or the new path object ?
... maybe we should go on Path

rik: do you have an example ?

brian: no

dirk: we should find one solution to solve both problems: JSON and Array

heycam: the JSON was meant to be able to express all segment types not 
normalized

dirk: the Array may be JSONified afterwards

brian: I can spec it and we can drop it if there is not much interest

<scribe> *ACTION:* Brian to spec the setting/getting of an array of 
floats for path handling [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action16]

<trackbot> Created ACTION-3429 - Spec the setting/getting of an array of 
floats for path handling [on Brian Birtles - due 2013-02-11].


      prioritization of remaining requirements

Cyril: next one is "Make it simpler to construct regular polygons and stars"

dirk: Tav has an action on it, but we haven't seen yet a proposal

heycam: let him and Doug work on it and see

cyril: next "Make arcs in paths easier"

dirk: that's Tab's action

heycam: I had also the turtle command for rotation
... to ease the creation of pie charts

dmitry: I don't know the final decision, but next Raphaël adds 3 
commands for arcs (oval, arc, arc using 3 points)

<krit> http://raphaeljs.com/arc3.html

dmitry: I chose O and U

(dmitry drawing example on the board)

dmitry: the commands use the previous commands to get the missing parameters
... like the center, or start and end angles
... in most cases, the center will remain the same if you draw multiple arcs
... the basic idea is that the center is derived from the previous 
command, it is not specified in the current command
... I decided to use degrees, not radians

dirk: if the center does not change with an arc command but changes with 
another command, you have 2 store 2 last points
... Canvas arcTo commands are more complex that Dmitry's

dmitry: there is also the arc3 with 3 points

dirk: it is a nice demo but I don't know how useful it is

alex: it is part of HPGL since 40 years

rik: most of the time you want to use the arc segment to be hooked to 
the previous path

dmitry: it has been heavily requested by the community

heycam: we have one method in SVG, 4 in Canvas, dmitry's ones, that 
makes 8 different arc commands

cyril: does this go in SVG 2 or in SVG.next ?

rik: Tab should take care of that

*RESOLUTION: "Make arcs in paths easier" may go in SVG.next unless Tab's 
actions are done in time for SVG 2*

cyril: next "Allow objects to be positioned along a path"

heycam: this is the thing Doug refers to ShapePath

alex: just define each shape as each glyph in a font and use textPath

dirk: SVG fonts are not supported in all browsers

heycam: markers could be used too

alex: it is also using several animateMotion elements with offsets and 
not moving

*RESOLUTION: "Allow objects to be positioned along a path" is already 
solved at least using 2 different ways so no action required*

cyril: next "Require automatic text wrapping in arbitrary shapes 
compatible with CSS"

alex; isn't it implemented in Inkscape and CSS refused

shane: that's why it says compatible with CSS

*RESOLUTION: Automatic text wrapping will go in SVG.next unless Tav 
comes with text*

cyril: next "Support glyphs being aligned to different baselines, 
perhaps by using existing or improved CSS properties"

alex: don't we have that ?

heycam: using dominant baseline and so on
... the part about baseline has to be rewritten to use CSS

<scribe> *ACTION:* heycam to insure that the text chapter talks about 
baseline in terms of CSS features [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action17]

<trackbot> Created ACTION-3430 - Insure that the text chapter talks 
about baseline in terms of CSS features [on Cameron McCormack - due 
2013-02-11].

cyril: next "Clarify the stretch method for textpath"

http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html

heycam: I thought this was more about filling in some wholes about textPath

alex: Tav's stretch is already spec
... Corel implemented

erick: this is not fully specified

alex: the last examples from Tav's page are not specified
... some fonts have copyright issues that don't let you have access to 
the point data so manipulations of glyphs is not easy

dirk: Canvas is supposed to expose the glyph to JavaScript

rik: but it's not implemented

alex: maybe because of the copyright issue, to avoid ripping fonts

dirk: users should not have access to the glyph data

alex: there are flags in the font package that say do not modify me

heycam: do we require the stretch method to have particular behavior

dirk: no, it is already specified in 1.1

heycam: do we add constraints on how the strectch is made

dirk: it could be a separate module

*RESOLUTION: defer "Clarify the stretch method for textpath" to SVG.next*

Cyril: next "Have a way to specify flip-invariant text"

alex: I would use SVG Tiny ref transform to stop the flipping

cyril: we have accepted transform="ref" (point 90)

alex: I think we should add it to the use case list for constrained 
transforms

*RESOLUTION: consider "Have a way to specify flip-invariant text" as 
part of the constrained transforms item*

cyril: next "Deprecate the use of xml:space to affect layout and will 
use the CSS white-space property"

heycam: partially done, I'll do the rest soon
... there was a discussion of mapping xml:space with whitespace using 
user style sheet
... we do that under the hood in Firefox
... but that creates problems when inheriting the whitespace property of 
between SVG and HTML

*RESOLUTION: "Deprecate the use of xml:space to affect layout and will 
use the CSS white-space property" is still part of SVG 2*

cyril: next "Allow transforms on tspan"

dirk: it is already the case
... due to the rewrite of the interfaces

heycam: it probably needs an example

*RESOLUTION: "Allow transforms on tspan" is covered in SVG 2*

cyril: next "Support Coons patches"

heycam: Mesh patches are already added by Tav

cyril: I still have an action to look at freeform gouraud meshes
... but couldn't for this meeting

*RESOLUTION: "Support Coons patches" is already in SVG 2, we keep it*

cyril: "Have a video element in SVG namespace with the same 
characteristics as the HTML 5 video element"

alex: we have a discussion on this tomorrow
... I've invited Silvia Pfeiffer to talk about that

cyril: next: "Have stronger requirements for when to display tooltips"

dirk: that was a discussion we had already
... Doug needs to talk Rich

*RESOLUTION: "Have stronger requirements for when to display tooltips" 
still goes in SVG 2, pending on Doug and Rich discussion*

cyril: next "Support pointer events sensitive to alpha, subject to 
security constraints"

alex: the use case is for Farmville
... having a PNG with alpha and do hit testing on the images

dirk: maybe the should use canvas and hit regions

*RESOLUTION: defer "Support pointer events sensitive to alpha, subject 
to security constraints" to SVG.next*

cyril: next "Support HTML document wide events (including hashchange) 
apply to SVG documents when they make sense"

heycam: we should still do that, I will do that

erik: that's already implemented in browsers, at least some part of it

heycam: I wouldn't be surprised if the 
document.addEventListener('hashchange' ... work

dirk: maybe we move these attributes

heycam: they may have moved already to Element

dirk: we can push other specifications to move some to Document or Element

heycam: we need to say SVGElement implement GlobalEventHandlers

<heycam> 
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement

heycam: or we need to ask to move them to Element instead of HTMLElement
... I'll do that as part of the action

*RESOLUTION: "Support HTML document wide events" still in scope of SVG 2*

cyril: next "(may) Support drag&drop functionality"

erik: I have an action on that but it depends on the eventhandler thing
... we need only to add the attributes to SVG, the rest is specified in HTML
... I could start working on it

heycam: you could do that and leave out the event stuff

*RESOLUTION: "(may) Support drag&drop functionality" is still in scope 
for SVG 2, it is a small change*

cyril: next "Make it easier to detect if an mouse event is on the stroke 
or fill of an element"

heycam: done

cyril: next "Allow async/defer on the script element"

heycam: yes we should keep it
... I remember Boris being worried about a document.write related thing

*RESOLUTION: "Allow async/defer on the script element" is still in scope 
for SVG 2.*

cyril: "Support for non-negative speed on time containers (if we decide 
to include time containers)"

brian: we do negative speed in Web animations, only on the root

*RESOLUTION: "Support for non-negative speed on time containers" is part 
of Web animations*

cyril: "Support path-based animations of pairs of attributes"

brian: I'm not sure about that

heycam: it came from applying x,y attributes from animateMotion and 
apply it to two elements

brian: the model of Web Animations should support that
... given solid use cases, we can add it to the next version of Web 
Animations

*RESOLUTION: "Support path-based animations of pairs of attributes" will 
be added to future Web Animations, pending solid use cases*

Cyril: next "Define all explicitly undefined parts of the SVG 1.1 spec 
(wrt to to-animations)"

brian: that will be covered in SVG integration to Web Animations
... to animations in SVG is weird

*RESOLUTION: "Define all explicitly undefined parts of the SVG 1.1 spec 
(wrt to to-animations)" will be covered in SVG integration with Web 
Animations*

cyril: "Define all explicitly undefined parts of the SVG 1.1 spec (wrt 
to to-animations)"
... "Allow CSS-transitions-like animations"

brian: it's about snapshoting

*RESOLUTION: "Allow CSS-transitions-like animations" is deferred to a 
further version of Web Animations, pending more details*

cyril: "Allow linear interpolation for properties which were previously 
discrete"

brian: it's about text anchor
... Chris should be doing it

ACTION-3209

<trackbot> ACTION-3209 -- Chris Lilley to write up a proposal for 
allowing linear interpolation of properties that were previously 
discrete but could be reasonably interpolated linearly -- due 2012-01-20 
-- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3209

shane: in CSS this kind of thing doesn't really make senss
... Tab proposed to snapshot the page in the first and final state and 
to interpolate everything
... there is a good chance that CSS will go in this direction

*RESOLUTION: "Allow linear interpolation for properties which were 
previously discrete" is deferred to SVG.next, unless Chris comes up with 
a proposal*

cyril: next "Support animation using a transform-list"

brian: that is in CSS transforms

dirk: this is linked to the decomposition of transforms

brian: SVG integration with Web Animation will refer to this decomposition

*RESOLUTION: "Support animation using a transform-list" is in scope of 
Web Animations*

cyril: next "Support motion animation of a specified speed"

brian: defered in web animations
... we think we can address that with the model, but not in the first 
version

*RESOLUTION: "Support motion animation of a specified speed" is deferred 
to a future version of Web Animations*


    Summary of Action Items

*[NEW]* *ACTION:* Brian to spec the setting/getting of an array of 
floats for path handling [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action16]
*[NEW]* *ACTION:* Cameron to add dash control to SVG2 [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action08]
*[NEW]* *ACTION:* Cameron to add length shortcuts to SVG DOM [recorded 
in http://www.w3.org/2013/02/04-svg-minutes.html#action01]
*[NEW]* *ACTION:* Cameron to follow-up aligning with global HTML 
attributes in SVG [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action06]
*[NEW]* *ACTION:* Cameron to mail HTML people about moving data to 
Element [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action05]
*[NEW]* *ACTION:* Cameron to relax referencing requirements (issue-2295) 
[recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action04]
*[NEW]* *ACTION:* Cameron to spec auto-sized images [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action02]
*[NEW]* *ACTION:* Cyril to specify shared-path segments [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action09]
*[NEW]* *ACTION:* Dirk to investigate applying CSS transforms to SVG 
when it is the root element of the document [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action03]
*[NEW]* *ACTION:* Erik to add non-scaling stroke to SVG2 [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action07]
*[NEW]* *ACTION:* heycam to insure that the text chapter talks about 
baseline in terms of CSS features [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action17]
*[NEW]* *ACTION:* heycam to write up examples and text for marker-mask 
[recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action10]
*[NEW]* *ACTION:* Rik to add new procedural methods for catmull-rom 
[recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action14]
*[NEW]* *ACTION:* Rik to add the extendPath and addPath methods to the 
SVG 2 [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action13]
*[NEW]* *ACTION:* Rik to edit the SVG 2 spec to add the possibility to 
set the d attribute using a Path object [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action12]
*[NEW]* *ACTION:* Rik to look at how to attach a path or shape object to 
an SVG path element [recorded in 
http://www.w3.org/2013/02/04-svg-minutes.html#action11]
*[NEW]* *ACTION:* Rik to specify the stringifier method for the Path 
object [recorded in http://www.w3.org/2013/02/04-svg-minutes.html#action15]

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.137 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-02-04 06:30:21 $

------------------------------------------------------------------------


    Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01
Check for newer version athttp://dev.w3.org/cvsweb/~checkout~/2002/scribe/  <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/>

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/cabanier: how is the quality of what is produced? If you have /cabanier: how is the quality of what is produced?/
Succeeded: s/Array v/Array/
Succeeded: s/used to/used too/
Succeeded: s/but the impleme//
Succeeded: s/transformed ref/transform="ref"/
Succeeded: s/in SVG/in HTML/
Succeeded: s/resolution:/RESOLUTION:/g
Found ScribeNick: nikos
Found Scribe: Cyril
Inferring ScribeNick: Cyril
ScribeNicks: nikos, Cyril

WARNING: No "Present: ... " found!
Possibly Present: ACTION-3427 ACTION-3428 AlexD Cyril Cyril_ alex all birtles brian cabanier dirk dmitry ed erick erik glenn heycam https jun krit left nikos nikos1 rik scribenick shane shanestephens_ shepazu stakagi svg trackbot
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL:http://www.w3.org/2013/02/04-svg-minutes.html
People with action items: brian cameron cyril dirk erik heycam rik

WARNING: IRC log location not specified!  (You can ignore this
warning if you do not want the generated minutes to contain
a link to the original IRC log.)


[End of scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
diagnostic output]


-- 
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/