SVG Working Group Teleconference

01 Mar 2011

See also: IRC log


+1.649.363.aaaa, tbah, +1.425.868.aabb


<trackbot> Date: 01 March 2011

<dholbert> SCRIBENICK: dholbert


<anthony_nz> http://dev.w3.org/SVG/modules/compositing/master/Overview.html

AG: That has the latest version
... Doug originally merged the language and the primer
... It was originally in 2 parts, each property had 2 sections. I've merged it all together & added a few examples to it
... I also had a few coments from people on the mailing list; addressed those
... I also put simplified versions for the blend mode equations. Equivalent to more complicated earlier forms

<pdengler_home> i'm in

AG: I believe this is ready for last call for publication & we should take it to CR
... Doesn't have a test suite, but the examples can be used as (to make) tests

CM: So we've got enable-background - is that same definition as in 1.1?

AG: No - it's different from filter enable background, if that's what you're asking

CM: Ah, so it only applies to filters in 1.1?

AD: This new rewording is meant to clarify that a bit

CM: Have there been many changes since we last looked at it?

AG: Not really - some of the equations have been tweaked
... (asks AD about accumulate w/ enable-background)

AD: The big problem w/ integrating porter-duff w/ svg enable-background accumulate is you have to do a removal step
... Only matters in porter duff modes other than "over"
... Once we worked out that you needed that technique, it required a lot of math to work out how that works for all of the modes

CM: Is that in the spec?

AD: Yes

AG: What about accumulate?

AD: You only need to worry about accumulate if you're applying porter-duff to that group

<pdengler_home> Is someone scribing

CM: I'm happy for this to go to last-call

ED: One little thing - it's normatively referencing 1.2

CL: 1.2 tiny?

ED: No, 1.2 full

AG: I can make that 1.1 instead

CL: Yeah, do that

DS: So this in itself is sufficient for anybody to do compositing?

AD: From an author's point of view, they only really care about the blend modes, since they're in photoshop & illustrater. The porter duff modes being in there help it work with Java 2D

CM: Do you have some examples of cool stuff you can do with porter duff?

AD: Original paper has some - e.g. plus lets you smoothly blend between two videos

CL: It'd be handy to have those sorts of examples in the spec

AG: Can I reference Second Edition?

CL: Yes, you can't not do that
... In the references section, it mentions PDF, but that's not actually used/cited anywhere

CM: Actually none of those references are used/cited anywhere

AG: Yeah, I should go through that

CM: Do you know if the spec builds properly?

AG: Yes, I think we got that working
... So with the references ...

CM: If you're going to have a normative reference, it'd be SVG 1.1
... If you wanted to include an explicit actual reference/citation in the spec, just do it the first time you mention SVG

RESOLUTION: Move compositing spec to last-call, after references have been fixed

DS: There's a couple of things you'll need to fix in the images - some are missing xlink:href namespace decl

<ChrisL> ACTION: ChrisL to request puiblication of compositing spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action01]

<trackbot> Created ACTION-2982 - Request puiblication of compositing spec [on Chris Lilley - due 2011-03-08].

DS: Also, some of the images are using a raster as the background, and when it blows up, it looks really bad.
... I'll make a SVG version of that background that you can use

<scribe> ACTION: Doug to fix the images in the compositing spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action02]

<trackbot> Created ACTION-2983 - Fix the images in the compositing spec [on Doug Schepers - due 2011-03-08].

DS: As a general rule, where we have images in the spec, I'd like to have SVG with a fallback to the PNG, rather than having a PNG that links to SVG

CL: That's good if it's using SVG 1.1, but if it's using something newer...

DS: for newer features, we can make a mockup using SVG 1.1

CM: Might have to use a PNG for mocking up some things

DS: Sure, we can do that if we need to

RO: Main issue I have w/ enable-background is (with filters) -- if you have an input image bigger than the viewport, and you're filtering it, you might need to sample regions of the image outside of the viewport. What that means is, when you've got enable-background operating, you can't apply normal viewport clipping

CL: Can't you calculate how far out you'd need?

RO: You can, but some filter primitives require that you'd draw the whole background
... Normally the natural thing to do is to clip to the viewport at the beginning
... it's possible to have things that are infinite in extent, like a tiled CSS background
... so no one has implemented it correctly yet, so it's not clear that it's implementable

<shepazu> (anthony, the following files need an xlink namespace declaration, in http://dev.w3.org/SVG/modules/compositing/master/examples/ : compop-porterduff-examples.svg, compop-blend-examples.svg, clip-to-self-examples.svg )

AG: w/ references - did we write a requirements doc for compositing?

CL: Normally you don't need to reference that from within the spec

AG: I'll work on those references today and have it ready by next week

DS: Can you fix those xlink:href's too? and I'll work on the background thing

RO: Ah, so the issue that I talked about w/ clipping doesn't come up with this spec. But do we need enable-background?

AS: So the standard blending modes are just using alpha compositing - don't need to worry about enable-background for those


AD: ... but with the more complex ones, it's important

RO: So with the new rectangle thing, do we need that, or can we infer that?
... We can probably optimize that automatically

AG: It's an implementation hit, and I'd put it in because someone requested it

CL: Let's keep it in the spec, but later add a comment saying that it's not mandatory and can be dropped
... for last-call

RO: It adds extra work for us to do that clipping, when it's not always necessary/useful
... In the clip-to-self property, it talks about whether you use bounded vs unbounded operators
... it talks about the shape of the object. But is that well-defined for all shapes? e.g. circle with stroke of dashes - what do we clip to?
... so if it's dashed with opacity 0, do we consider that part of the shape of the object?

CM: If it's fill:none, it wouldn't be included, but if it's opacity 0, it would

AD: This is partly for compatibility with Java 2D

RO: We had similar issues with canvas
... I think this needs to be clarified - all these edge cases, whether pixels are affected or not

AD: yeah, which pixels have been 'touched'

RO: We need to define what 'touched' pixels means

CM: spec says -- "for filled and stroked shapes and text, the object is directly converted to a clipping path"
... Perhaps that means 'if you stuck it in a <clipPath>'?

CL: No, it's clipped as if it _was_ a clipping path

<scribe> ACTION: Anthony to clarify clip-to-self behavior [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action03]

<trackbot> Created ACTION-2984 - Clarify clip-to-self behavior [on Anthony Grasso - due 2011-03-08].

RO: I think it'd be useful if it matched clipPath behavior

AD: but clip-to-self works with antialiased edges

RO: We can say the shape is the same, but the edges are up to the implementation

CL: We shouldn't use wording that suggests that anything magical happens with an anonymous <clipPath> under the hood

CM: Maybe we should express it in terms of a mask instead?

AG: so it's just 'whatever pixels are painted'?

RO: That's still not entirely clear
... It has to be precise, but we shouldn't so much suggest how to implement it

AG: So are we still happy to publish, then?

CM: So we've got note about enable-background new, the references, clip-to-self -- is that all that's required?

RO: So we don't leave last-call until there are 2 implementations & tests?

DS: No, candidate-recommendation is where that happens
... (and you might go back to last-call after being in CR)

Advanced Gradients

<anthony_nz> http://www.w3.org/Graphics/SVG/WG/wiki/images/f/fc/SVG_Advanced_Gradients_Requirements.pdf

AG: So this was discussed last year - making some sort of feature better than the current gradients that we have, because they're fairly basic
... I drafted some use-cases & requirements for some advanced gradient feature
... I think SVG 2 would look a bit poor with just the basic gradients that we have

CM: Given how often people have been asking for advanced gradients

AG: I've left the draft pretty open-ended in terms of focusing on specific tech
... Some of the input that went into this came directly from authors & usability specialists - the people who actually do the drawing
... I haven't committed it yet since I don't really know where to stick it
... (The wiki wouldn't let me upload an HTML document, so that's why it's a PDF right now.)
... (puts spec on projector)
... The first part is just boilerplate. The bits that are different from the template are the introduction...
... So 'usage scenarios' is the first bit that I added.

CM: So are these what your designers said they wanted?

AG: Yeah - they wanted to be able to produce naturalistic images in a pretty simple way, with a compact representation
... they're used to it in photoshop, where it works but is difficult to lay down all the mesh points
... They want something between that and what they can do in illustrator.

DS: Would be nice to somehow combine gradients

AD: Tav had some demo page. I had to implement some of that and it was quite hard

<tbah> http://tavmjong.free.fr/SVG/MESH/Mesh.html

AD: I did a lot of investigation. What you'd have to do is provide a triangular mesh and at each mesh point provide a normal

DS: suboptimal from an author's point of view

CL: I'm wondering if you could lay out your mesh, and at each point use luminance to get a height, and then calculate normals based on that

AD: The phong formulas assume light reflection, and that requires an angle of incidence w/ triangle, which you need the normals up-front for.. I guess the conclusion is it's non-trivial

DS: So it's non-trivial to author?

AD: It's trivial with authoring tools like Maya, etc

AG: But what about hand-authoring to tweak something?

CM: What about animating it?

AD: If you define the syntax right, it wouldn't be too hard
... Making the object move might be tricky - but making it look like the light is moving would be trivial (by animating the normals)

CM: Can you do that with filters, too?

AD: Yeah

AG: So -- I put a few examples in there of the usage scenarios
... (opens an artistic effect demo) At the moment, to do this in SVG is nontrivial / impossible

CM: Do you have a summary of tools & which kinds of gradients they can do?

AG: No, not yet

CM: If mesh gradients are tricky, they might still be worth it if people are familiar with them

AG: (scrolls to 'special considerations for advanced gradients')
... So there's a section for memory & processor requirements

DS: We should ask other authoring tool companies what they think about this

ED: Scribus has mesh gradients, and they export SVG, but I don't know what syntax they use

TB: Now that Cairo has support for mesh gradients, there's a lot of interest in them

AG: I noticed you have a lot of good information on that link you dropped in - would it be possible to put that into advanced gradients use cases/requirements?

TB: Sure, you can take anything you want

AG: Yeah, it'd be nice to just take that research and put it into a W3C document

DS: In a Google-search for cairo gradient mesh, the fifth link is Tav's document

TB: mm hm

CM: Anyone know if other graphics libraries like CoreGraphics have advanced gradient support?

DS: So it sounds like gradient meshes are certainly of interest - regardless of what else we do, we should probably have gradient meshes

AG: One of the things designers want is to control how far color spreads out from a point

DS: More like an ellipse or like a circle?

CM: so normal gradient meshes do color interpolation between the three points

TB: tensor meshes have extra control points - that is implemented by cairo

DS: We should talk to the cairo guys

RO: We can look at the code & documentation

AG: I added animatability as one of the requirements
... Also, 'syntax can be easily authored by hand', or at least easily understood by authors
... also, I added a requirement that we maintain compatibility with CSS where possible

DS: They'll likely follow whatever this spec does

<ChrisL> A new CAD mesh segmentation method, based on curvature tensor analysis

DS: There was an action on Tav to talk to Tab Atkins

<ChrisL> Computer-Aided Design

<ChrisL> Volume 37, Issue 10, 1 September 2005, Pages 975-987

TB: Haven't done that yet

<ChrisL> Guillaume Lavou�Corresponding Author Contact Information, E-mail The Corresponding Author, Florent DupontE-mail The Corresponding Author and Atilla BaskurtE-mail The Corresponding Author

CM: Easily authoring by hand will be tricky - even authoring paths by hand is difficult

AG: I meant more that it's easy to follow. With paths, you can look at it and see "cubic bezier, etc".

CM: Ah, yeah - so just 'not a binary blob' I guess

DS: So RE animation -- the gradient itself must be animatable, I guess

BB: So what about diffusion curves?

AG: Authors like that concept, but they have some problems - e.g. how they interact with each other. They'd like more control over how the color diffuses and what the color stops are
... and they'd like to make it so only one side will diffuse

<tbah> I just got cutoff and the access code is "restricted" at this time.

AG: so it has things they like, but they have issues with it

<roc> shepazu: cairo's "mesh patterns": http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c#n801


<tbah> OK, I'll probably just head off to lala land. Thanks.

AG: so I'll make the suggested changes, and then we can publish at some point

<scribe> ACTION: Anthony to fix advanced gradients spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action04]

<trackbot> Created ACTION-2985 - Fix advanced gradients spec [on Anthony Grasso - due 2011-03-08].

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam


CL: [summarises history of downloadable fonts]
... [summarises why SVG fonts were devised, and what WOFF does]
... so coming into SVG 2 we have WOFF which is everywhere now
... we can do nicer things in svg now that we have this font format
... it's way better internationalized than svg fonts
... i looked at using graphite with svg fonts, but there'd be a lot of work for that
... and it's not the direction the industry is going
... so my proposal is to mandate woff in svg 2
... i'd like to see it in batik
... it's already in firefox since 3.6, and opera since 11.1 or so
... in ie9 since preview 2
... the only format that mobile safari used to support was svg fonts
... which is why fontsquirrel etc. output svg fonts
... i believe the new mobile safari supports woff

ED: are there any other formats that should be mandated? any reason to just require woff?

CL: if you've got a ttf/otf font you can convert it to woff easily
... some browsers support linking to native ttf/otf, some don't
... most of hte font vendors hate the idea of link to tt/otf
... even though they know it's trivial to convert between them and woff
... it's the difference between picking up a wallet on the street, and taking it out of a car
... we've been careful in the fonts wg to not require any browser enforcement
... so the font guys are happy to license fonts for desktop (otf) or the same font in woff for online
... it's a big deal. there's a whole new font industry now.
... and the free font industry too, the open font library
... if we require it that you're linking to raw otf then it's going to ruffle a lot of feathers

RO: ie9 does allow linking to raw ttf fonts, if they've got the correct permissions bits set

CL: right, and also enforces a same origin restriction

DS: but nobody objects to requiring woff?


JF: what is the current status with html5 and woff?

CL: html5 doesn't mention woff, because it doesn't talk about formatting as such
... it's css that talks about formatting
... currently it's completely separate. the css3-fonts spec which says how to link to fonts.
... the woff spec references css3-fonts, but there's no requirement in css3 to support woff

JF: you are suggesting svg2 to reference directly to woff, not just css3-fonts?

CL: right, because css3-fonts doesn't require any particular font format
... if that requirement moved to css3-fonts, we wouldn't need to have it in our spec
... for the moment i think it makes sense to put it in there
... we can take it out later if css3-fonts starts to require woff
... we should also link to css3-fonts instead of css3 in svg2
... which also gets us the cool new features

JF: if we mandate the use of woff in svg, does that mean html5 implementations also need to support woff?

DS: svg support is not required by html5
... but an html5 & svg user agent would be required to

CL: the implementaitons of html5 already have woff support, mostly

JF: i'm just wondering if we should align with html5

CL: we can suggest that html5 requires that, but i suspect it won't, because it's css's job to do the rendering
... but i notice that epub3 requires woff

RESOLUTION: We will mandate WOFF support in SVG 2.

AD: should we consider being able to encode it inline just like in svg fonts?
... so we can have self contained files with font data?
... that's a major benefit of svg fonts

CL: something other than using a data uri?

AD: something like data uri

CL: yes that would already work

RO: how abotu the size of a woff font compared to an svg font?

CL: svg fonts have not much overhead, once gzipped is reasonable

RO: MB-sized data uris work fine in gecko

AD: it's be nice to have a better encoding for data uris

CL: that's a general thing for binary stuff, xml isn't very good at including binary stuff

AD: base64 was designed in an old era that doesn't really apply
... for an era when you only had 6 guaranteed bits

DS: just write an rfc for it

CL: you could an extra encoding, other than ",base64" to data uris

AD: base64 decoding is slow
... if the encoding was simpler...
... so something similar to base64 but using more bits
... base64 requires a lot of bit shifting

CL: feel free to have at it. it's not for this wg to do, though.

SVG Fonts

ED: i wrote up a short page


scribe: this will require SVG 1.2 Tiny Fonts for SVG 2, but to leave out the complex fonts for a separate module

AD: i think that's a sensible thing, since so many devices already implement 1.2T SVG Fonts

ED: SVG Tiny 1.1 defined it too
... but better defined in 1.2T

CL: the tiny fonts are simpler, you don't have any content as a glyph
... so all the cool stuff you can't do in opentype, you can't do in Tiny SVG Fonts
... but you can build it on the fly with script
... some things tiny svg fonts can do that opentype can't do
... various path shapes aren't allowed in opentype, like self-intersecting curves, and many requirements on curve control point positions

BB: is that an extra feature?

DS: it's ease of use

CL: it's extra stuff that you have to do with an opentype font
... you can mix cubic/quadratic curves in the same glyph, whatever you want
... producing something on the fly, or draw a handwriting font, is more tractable using svg fonts

ED: altGlyph isn't part of Tiny fonts

DS: i think we should be looking at a variety of possible options for SVG2
... one of them is allowing a <glyph> to be inline, so it doesn't have to be associated with a font parent
... could just be a glyph inline

(some discussion about y-up coordinate systems)

BB: i want to know what we get by requiring 1.2T fonts in SVG2
... so we get access to the path data, and it's easier to author

DS: and also it's embedded in one file

BB: which you can already do with data uris

AD: there are 100s of millions of devices with Tiny fonts out there
... and there's lots of content on mobile that supports it. all the ipad stuff is using Tiny fonts.

<ChrisL> data uri kitchen http://software.hixie.ch/utilities/cgi/data/data

BB: by the time svg2 out those devices will have woff support

AD: it's a backward compatibility thing
... you can write some script to modify the font on the fly

CL: another concrete benefit is that it's already widely implemented on some desktop platforms, and almost all mobile platforms

BB: so backwards compat

DS: authoring tools too

AD: corel draw e.g., you can click export and it will subset system fonts and turn them into svg fonts

CL: since corel draw 8

CM: inkscape can generate svg fonts too

DS: it's fairly lightweight, not particularly difficult to implement
... there are lots of tools that already do it, it solves some use cases that woff doesn't, why not do it?

JF: i'd like to talk about use cases in the japanese market
... in the epub wg we talked a lot about the use of svg fonts and woff fonts
... we found important use cases for svg fonts
... the first is to use svg fonts to support emoji characters

<ChrisL> s/emojoy/emoji/

JF: which are part of unicdode 6.0
... they can be animated
... opentype cannot support emoji characters, but svg fonts can
... emoji is very important for japanese, since there are many mobiles targetted towards keitai users

RO: but that's full fonts, not tiny fonts?

JF: yes
... the other use case includes in japan we need to support variation characters
... the current implementation of browsers and ereading systems does not support IVS yet
... but that's easy with svg fonts. you can easily define variation characters using the svg font mechiansm.
... you can just use the variation selector, so that text content is a proper unicode sequence
... you can use svg font defined variation characters

BB: for emoji, is that a bounded set?

JF: yes

BB: do you ever have e.g. novels where they want to use a new character that's not in the set?

JF: also there can be one or two special characters in a novel that are not covered in unicode

BB: with the unicode variant, is this a backwards compat issue?
... i believe in firefox we allow variants to be selected from fonts

RO: why wouldn't the variant selectors work with opentype?

JF: because some leading systems, their OSes don't support variation selectors
... and it's sometimes difficult to implement on those systems

BB: so it's a compatibility issue there. it is possible to do that with css3 and opentype, but some of the devices don't support that?

JF: yeah
... it's a kind of lightweight workaround

BB: with the emoji, if there are new ones publishers want to use, it sounds like we need another feature

JF: we think that is not that important, and it can just be a user defined feature

CM: (shows some examples on the board)

JF: i have one suggestion for svg fonts
... fonts in tiny do not support vertical alignment
... we'd like to see that supported by svg fonts in svg2

CL: i'm hearing a proposal that it should be tiny fonts as implemented, but possible with alyGlyph and adding the vertical stuff
... i think we may have removed vertical font support because vertical text wasn't supported in tiny

AD: the people doing the tiny font subset weren't interested in vertical text

ED: opera has the horiz-adv-y for svg fonts as well
... it's a small addition

DS: the proposal is svg2 includes that starts with 1.2T SVG Fonts with a couple of additions

ED: and dividing it in to an optional module for svg full fonts

DS: pushback?

BB: i just want to be clear what the benefits are
... we should be arguing why we need it, not why not

DS: there are arguments from both sides

RO: i have a question
... one that i'd like to understand is...
... let's assume there are good use cases supported by tiny fonts
... we know that we basic or nonexistent shaping in tiny fonts
... i assume these use cases are also valid use cases in the context of indic characters, which require complex shaping
... what's the plan to support those use cases in those languages?
... i think we need a plan, a story to tell -- how we'll support those use cases on the web
... we don't want to say we just won't support those scripts
... does it mean extend fonts to handle those scripts, or handling these use cases with a differently technology?

DS: talking to some font guys, i asked them are you guys interested in moving beyond what 1.1 full fonts have? to solve the real problems you have with fonts?

<ed> i would say tiny12 has basic shaping support, with arabic-form, so it's not nonexistent

DS: started taking about svg thing, but moved on to not necessarily needing to be
... that discussion i think should happen outside the svg wg

AD: you're spot on with the shaping stuff
... it's effectively programmatic
... the support for arabic in svg full fonts is pretty basic compared to what font engines can do
... you virtually need a programming lgnauge in the font to do the shaping

RO: opentype does support shaping for indic
... it's a lot of custom logic in the font engine

CL: it's in the font engine, so you've got all these tables, and if it knows how to do it then it does shpaing, otherwise it doesn't

RO: in practice everyone need to implement this for opentype shaping
... and there are open source ones like harfbuzz
... where i'm going is, are you guys saying that there'll be some new font tech that will solve it?

AD: no
... i think there are specialists in fonts/shaping who would be better to ask about future font techs

RO: if we extend svg fonts with advanced shaping to handle indic etc. we could say that's what we think will happen.
... or, we could say it's less work to say opentype where shaping is already solved, and extend an opentype based solution to address the use cases that would otherwise be solved by svg fonts

AD: company logos e.g. is a different kind of use case
... it needs to be accessible

RO: i'd like to have an answer to that question

AD: for the longer future?
... when we're talking about tiny


CL: [talks about investigating graphite-like support for svg fonts]

trackbot, close ACTION-2939

<trackbot> ACTION-2939 Look into batik failing filters-overview-01 closed

RESOLUTION: SVG 2 will mandate support for SVG Tiny fonts support, and SVG Full fonts will be specified in a separate module.

SVG IG Japan report

JF: first i'll talk a bit about SVG IG Japan
... SVG IG Japan, we started the activity two years ago
... core members consist of 8-10 people
... mainly interested in SVG for mapping
... we've had 7 f2f meetings int he past two years
... total number of people who have attended these meetings is over 20
... we invite guest speakers from, for example, google japan
... or from mozilla tokyo
... also w3c people like doug, who attended the first f2f meeting
... the main topic of discussion in SVG IG Japan has been SVG JIS standardisation
... and SVG extensions for mapping
... these are the two main topics we discuss
... there is an effort to make an SVG JIS standard in japan
... there have been three committees for standardising SVG
... the first committee translated the draft specification of SVG 1.2 Tiny, about three yesars ago
... then the second committee created a new SVG extension for mapping, that was in 2009/2010
... we (mozilla) are now working in the third committee, whose goal is to use the translation of SVG 1.2 Tiny to prepare for official publishing of SVG 1.2 Tiny JIS and extensions for mapping
... we have applied to have two official JIS standards: one for 1.2T, one for the mapping extensions
... we are currently working on the final stage of review, and we will finish this third phase of the committee by next March
... so you can expect to get these two JIS standards published some time before 2013

CL: once something has become a JIS standard, a few years later it's elegible to become an ISO standard, is taht right?

JF: three years ago we did the translation of 1.2T, and that's just a TS -- technical specification
... that's not an official JIS standard
... our goal now is to publish the official JIS standard, some time in 2012 or 2013
... that work will be finished by march

CL: the mapping extensions was started in 2009, is that dervied from the KDDI extensions?

JF: yes, exactly
... in the last two years we tried to align JIS SVG extensions and W3C/SVG specificaiton
... that was the reason why we proposed to create the new module SVG Tiling & Layers

CL: this is in japanese. will there be an english translation of the mapping part?

JF: yes

AD: there's an english description on the web
... and I've got a demo of a Tiling implementation

DS: along those lines, one of the problems was how to get the IP that KDDI might have around this, and I believe this is going to be solved in April?

JF: yes
... they decided to join W3C
... also they are very interested in joining the SVG WG
... to work on the SVG TIling & Layering specification
... that's their intention

CL: that's good news they're rejoining
... we want to understand the original principles, so that we don't accidentally change things they need

DS: you think 2012-13 is when you'll complete that part of the JIS standard as well?

JS: yes
... but ths SVG JIS committee to work on that standard will be finished in March

DS: maybe version 2 could have some changes?

JF: yes
... at first, we may start with two different specifications

DS: I've also been tlaking to other people, people from medical imaging, and other things where you are bringing in subsets of larger documents

<roc> ed: http://people.mozilla.com/~roc/LightPosition.xml the question is whether the light position should be the center of the circle or not

DS: and I talked to them about tiling and layering, and it's exactly what they're interested in, from a different perspective than mapping
... KDDI is also interested in HTML5 and TV on Web, from some other people
... I'd like to put before this group about having a mapping taskforce of the SVG WG that looks specifically at the topics of mapping, and what we could add to SVG2 without too much trouble to make it better for mapping
... I have a draft charter for that

<roc> ed: the spec says 'x' is the "X location for the light source in the coordinate system established by attribute ‘primitiveUnits’ on the ‘filter’ element.", which here is "objectBoundingBox", and http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox describes the object bounding box coordinate system in a way that implies 0.5,0.5 would be the center of the circle


<shepazu> 12http://www.w3.org/Graphics/SVG/map/map-charter.html

<shepazu> 12http://www.w3.org/Graphics/SVG/map/map-charter.html

<shepazu> 12http://www.w3.org/Graphics/SVG/map/map-charter.html

<shepazu> 12test

DS: it's not formal
... I'm open to suggestions
... one of the high level things we want for SVG mapping suggestions, if something can be generally useful for other content, make sure it's applicable to other contnet

AD: for example the tiling module, we did stuff for 1.2F, multi image resolution
... some of the KDDI datasets are like 5GB of map data
... but you can navigate it effectively with those kinds of extensions

DS: what is the implementation burden?

AD: it's not a lot
... the root container has a mapping from whatever coordinates space, WGS84
... when you load the child SVG content, it can be whatever it is, as long as it declares its mapping to WGS84
... the globalCoordinateSystem element is a sibling of the graphics, rather than a parent of the graphics, for some reason
... that's a bit of a mistake in the design
... it means that anyone that implements a standard graphics state stack to affect all the siblings

<roc> ed: http://people.mozilla.com/~roc/LightPosition2.xml the x and y coordinates for the filter primitive subregion *are* interpreted in object bounding box space in all browsers, so 0.5 0.5 is the center of the circle

CL: the way W3C did was to have a child <metadata> element with the mapping information in it

<roc> ed: the spec says "These attributes are defined according to the same rules as other filter primitives' coordinate and length attributes and thus represent values in the coordinate system established by attribute ‘primitiveUnits’ on the ‘filter’ element."

AD: the early prototypes used the rdf stuff
... then they decided they wanted a first class citizen element

CL: is this how it's specified in the JIS standard?

AD: yes

CL: has it shipped in implementations?

AD: probably not

CL: can we change it?

<roc> so I think it's pretty clear that those x and y attributes should be treated the same as the x and y in the light elements

CL: what timeline is there?

JF: I'm not sure, the JIS standard is in the very last stage

<roc> ed: but Opera and Batik treat them differently I guess

DS: it's going to mean content is not compatible, but it's not a big change
... and there will probably be other changes as well

CL: ISO has an errata process, corrigenda
... I assume that JIS also has such a process?

JF: yes

CL: we could put in feedback that way
... if something's going to move from being a sibling to being a parent, it's an easy change to make before oyu have much content
... but after, it's annoying

AD: this only applies to geographic transforms, nothing to do with tiling & layering

JF: I suggest to make a suggestion to Tagaki-san

AD: I've spoken to him about these changes, and the feedback he's given me is that they welcome what W3C suggests
... they also use ref() transforms from 1.2T, and they modifieid it to interact with the geographic transforms
... and that's not defined

CL: we can fix these things up

AD: I don't think they'd have a problem with converting the map data they already have

DS: to what degree is this client side, and what server?

AD: the server is responsible for producing all of the tiles

CL: the benefit is that you can connect to multiple servers

AD: one of the examples I've got is where they generate tiles from open street map
... from two different places

RO: should web browsers be able to display raw map data?
... all the mapping applications I currently see have interfaces that let you search, and apply overalys
... they're all using script
... is it something we really need to display map data, without using script?

CL: one provider can provide a script library to do that, btu it makes it difficult to use other providers' data
... the declarative information lets you easily merge it from other providers

AD: the primary benefit of the tiling module is that as you pan out, the resources are already released
... if I've got a dataset 100GB in size, map tiles of the world, I can just pan around and the browser just decides when to throw out cached tiles

RO: there are a lot of use cases like that, e.g. massive tables of data, an Excel spreadsheet
... those sorts of use cases need to be solved, but SVG shouldn't solve that general problem
... there are a bunch of features that mapping featuers have, even aside from the tiling and LoD stuff

JF: the charter mentions CSS WG

DS: that's a copy/paste error

JF: that makes more sense
... I'd like to discuss one thing
... SVG Map specification, the original one from Takagi-san, was a kind of profile of SVG
... that includes various extensions used for mapping
... after reviewing the specification in SVG IG, and in this group, we decided to modify the specification to split into two parts
... the first part is the Tiling & Layering
... and we think that it's the most important part of the specification
... and we should create a new module to provide such feature
... other features, such as Level of Detail, and the support of z-index, are removed from the original specification
... because we think these features are useful for other use cases
... so given that we wil start the SVG Mapping taskforce, I want to make sure is this still the right direction for us, to focus on the Tiling & Layering as a single module?

DS: since we'll be forming a taskforce specifically for this, I think that the SVG IG Japan, I think it's still useful for you to meet and discuss these things because of languagei ssues
... and you can give feedback to the TF and the WG in general
... but I think it should be focussed on by the mapping TF

JF: do you still think it's a good idea to continue developing the Tiling & Layering specification?

CL: as a separate specification, from the mapping stuff?

JF: or shoudl we create an SVG Mapping profile again?

CL: no I think splitting it out is good
... mapping gets split out, is smaller, and depends on Tiling & Layering
... that would mean it is more likely to be implemented
... it should continue to take requirements from mapping, but also requirements from other areas like medical imaging
... the way you split it makes sense

JF: the current feature set covered by the Tiling & Layering proposal is a good start for discussion?

DS: absolutely
... the other features you talked about you want generalised, we can talk about those in the SVG WG in general


JF: I've been involved in the EPUB standardisation, in the last 24 months
... especially I'm involved in the subgroup called EGLS [enhanced global language support] which specialised in new features of EPUB3 to better support global language, including eastern language
... currently IPDF is working on the new version of EPUB, 3.0
... that's a major revision of EPUB
... it's expected to be released in May
... major new features include support for multimedia functions -- video and audio -- as well as scripting and interactivity
... also supports global language capabilities
... also improved accessibility, enhanced styling and layout features
... there is a public review draft and it was released on Feb 15
... they are currently under review

<jun> http://idpf.org/epub/30/spec/epub30-overview.html

JF: here you can get the overview document
... EPUB3 actually consists of various parts
... that's the overview page
... there's also EPUB Publications, EPUB Content, EPUB Media Overlays
... also a list of changes from EPUB2

<shepazu> s/paste error/paste error, which I've now fixed/

JF: they're linked to from the overview document
... I will quickly summarise the important points
... one is that EPUB3 is based on HTML5
... EPUB2 used to be based on XHTML 1.0
... they use the XML serialisation of HTML5
... with namespaced SVG content
... for EPUB3, HTML as well as SVG can be the root document
... so you don't need to use SVG from inside HTML

CL: can you put HTML5 inside a <foreignObject> in SVG?

JF: yes
... both are possible

ED: is foreignObject required?

AD: it's required, and I think it's a subset of HTML elements that must be supported in foreignObject
... I think there's a restriction on the size of the foreignObject content

JF: EPUB used to be considered a text oriented format
... but now we can use EPUB3 for more layout oriented document, using SVG, or we can create comics -- graphically oriented documents
... that's good news for us
... for styling EPUB3, it supports CSS 2.1
... also supports several CSS3 modules
... the baseline is CSS2.1, but also supports CSS Speech module and css3-fonts, to use embedded fonts, including WOFF fonts
... it also supports css3-text
... and css3-writing-modes
... these two modules are very important to support vertical writing in Japanese lanugage
... we're working closely with fantasai and other CSS WG members to make sure these specifications are ready for use
... probably you know there is a new WD published on css3-writing-modes and css3-text
... which is referenced by the current draft
... EPUB3 also supports CSS MQ, css multicolumn layout, also some extensions specific to EPUB to support ruby
... it defines some EPUB-specific display properties
... EPUB WG decided to define the ruby module as a temporary solution, because W3C does not have a good specification for ruby

CL: html5 has some basic support for ruby, but doesn't have very good support
... did it not meet your needs, and you had to create a new one?

JF: yes

CL: it would be good to transmit that information to the HTML WG, ideally before LC

AD: EPUB doens't use css3 paged media module
... they say different screen sizes will make intelligent decisions
... their recommendation is to use SVG documents for exact page layout

CL: in the Content Documents, it says "restrictions on SVG 1.1"
... the last one is puzzling
... "it should include the width/height attributes on the svg element"


<ChrisL> http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions

scribe: if it's inline, you would use width/height
... but if hte SVG is the root, and you're displaying on different devices/screen sizes, and you want it to be displayed full size, why would you want to force width/height to be specified?

JF: I have no idea. I think it's a good idea to give feedback to the EPUB WG.

AD: judging by their overview document, for targetting different display sizes, use HTML -- but for fixed sizes, you would choose SVG

<scribe> ACTION: Chris to mail the EPUB WG to ask whether width/height on root <svg> elements should be allowed [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action05]

<trackbot> Created ACTION-2986 - Mail the EPUB WG to ask whether width/height on root <svg> elements should be allowed [on Chris Lilley - due 2011-03-09].

JF: there are several issues in the EPUB WG regarding SVG

<jun> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0129.html

JF: I sent some of them to the SVG WG mailing list
... the first one is the question about which version of SVG to use in EPUB3
... they currently refer to SVG 1.1 Second Edition
... I'll have to make sure that's the right choice

CL: yes
... second edition fixes hundreds of issues with first edition

<jun> http://code.google.com/p/epub-revision/issues/detail?id=63

CL: the last call disposition of comments is almost complete, same for the test suite
... so the next transition will be to Proposed Recommendation
... not clear what will come first SVG 1.1F2, or CSS 2.1

JF: it's good to hear that
... EPUB WG are very serious about their schedule
... they even said they will not publish EPUB3 if it will be delayed
... they will publish some time in May

<jun> http://code.google.com/p/epub-revision/issues/detail?id=76

JF: another questions is about the use of RelaxNG schema in the specification
... they currently use the schema published with SVG 1.1 First Edition
... it's not normative

CL: also it wasn't produced by the WG
... we did produce a schema for 1.2T
... we did plan to produce one for 1.1F2 based on that
... that's hard work, we couldn't get someone to do it on contract
... we would love to have a schema that murata-san produced for us, since he knows relaxng very well
... but not starting with the 1.1F2 one, since it's just a DTD conversion

JF: what can we do about this?

CL: I can write to murata-san and ask him about this

JF: is there any plan to prepare a normative RNG schema for 1.1F2?

CL: it was planned
... I'm not sure it would get published at the same time as the spec
... we could produce another specification called RelaxNG schema for SVG 1.1F2
... in general W3C is not putting schemas under technical reports
... it puts them somewhere else
... we normally have a dated schema, as well as a current one
... a simple standards track spec for the schema would be ok to do

JF: we are happy to review his result, to make sure it reflects the changes in second edition?

CL: ye

<scribe> ACTION: Chris to contact Murata-san about an RNG schema for SVG 1.1 Second Edition [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action06]

<trackbot> Created ACTION-2987 - Contact Murata-san about an RNG schema for SVG 1.1 Second Edition [on Chris Lilley - due 2011-03-09].

JF: as you may notice, SVG animation is not allowed in EPUB
... and some of you might be happy or unhappy with this

CL: I felt it was OK, and I understood why
... e.g. there are ebook readers that have unpowered displays
... but I see scripting can also be supported

AD: peter sorotokin said that it was because it was just thought to be not important

BB: if you're targetting manga, you can get manga on keitai that are animated

JF: we are about to change the animation feature in SVG 2.0, so I think it's not a good idea to include it in EPUB3

DS: so for EPUB4

CL: I can understand it
... that's fine

JF: do we want to suggest to use CSS Animation?

CL: the two are being harmonised, so neither is more stable
... I would suggest to use the harmonised result of that, which can be used from SVG or CSS
... in EPUB4

JF: the next issue is about the CSS properties defined in SVG
... people think we will probably prepare one stylesheet to cover both SVG and HTML content
... in that case, is it OK to use SVG specific CSS properties in ... ?

CL: each specification can add more properties
... CSS is the set of all defined properties
... and they can all go in one style sheet
... you can use CSS3 namespace selectors to select SVG element explicitly

JF: css namespaces is not used in EPUB3
... if you use CSS namespaces, there is no problem to share the single style sheet for both SVG and HTML

<ChrisL> http://www.w3.org/TR/css3-namespace/

<ChrisL> CSS Namespaces Module

<ChrisL> W3C Candidate Recommendation 23 May 2008

JF: EPUB WG is planning to develope some kind of EPUB check program
... they plan to use W3C CSS validation service within their check program
... they want to see the support of some kind of EPUB3 profile as one of the profiles supported by the css3 validator

DS: if they are willing to do some work on that, I don't think that will be a problem

<scribe> ACTION: Talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action07]

<trackbot> Sorry, couldn't find user - Talk

<scribe> ACTION: Christ to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action08]

<trackbot> Sorry, couldn't find user - Christ

<scribe> ACTION: Chris to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action09]

<trackbot> Created ACTION-2988 - Talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [on Chris Lilley - due 2011-03-09].

JF: another issue is about font embedding

<ChrisL> s/Christ/@SVGesus/

JF: in EPUB3, the support of WOFF format is mandatory
... you can also support SVG Fonts optionally

CL: I was happy with it until today, when we decided we were going to require SVG Tiny font support
... maybe that changes it?

JF: EPUB3 references SVG 1.1 though

CL: in SVG 1.1, Tiny fonts don't have vertical

<ChrisL> but 1.1 fonts do

DS: what is the lifecycle of EPUB? when will EPUB4 come out?

JF: some of the WG members have started working on the next version
... some of the features are omitted from the EPUB3 draft
... some of the features might take some time to be finished, so they're moved to the next version

DS: how long between EPUB2 and EPUB3?

JF: over three years now
... some people want to have EPUB 3.1

DS: so anywhere from 1-4 years is likely for another version of EPUB

JF: our feedback to the EPUB WG is we are happy with the mandatory support of WOFF?

CL: yes

JF: and suggest to support the Tiny subset of SVG Fonts

CL: with vertical support

DS: that's our suggestion

JF: should it be mandatory in EPUB?

CL: I would say that's our feedback, it's up to them what they decide, but they may like to take into account that we just resolved that SVG2 will have SVG Tiny fonts support plus vertical support

AD: if someone were to be interested in mobile again, would we want to have another module for 1.2T for SVG Tiny Fonts with vertical support?

CL: if we had infinite time

AD: it could be reused for SVG2

<ChrisL> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite

JF: one more issue

<jun> http://idpf.org/epub/30/spec/epub30-ocf.html#font-obfuscation

JF: font embedding
... it's about font obfuscation

CL: are you asking is the right thing to do?

JF: yes
... the current version of EPUB has similar features
... in order to allow the embedding of OTF fonts
... now EPUB decided to support WOFF fonts
... so it seems possible to just embed WOFF fonts without using obfuscation

CL: I think obfuscation... it's easy to undo
... so it's a picket fence, it's not protection in any sense
... but you have to actively do something to circumvent it
... I feel that information is better than a half hearted attempt at protection
... with WOFF it has the license right there in the file, which I think is better
... I don't think it's actively harmful to have the obfuscation, and now that you have woff, you shouldn't need it
... but if there is an agreement to have it then maybe there is some value

AD: XPS introduced the same obfuscation in their pacakaging, and it's more to make the foundries be happy to embed fonts

CL: I know that many foundries are happy with WOFF
... I think we can question the value of the obfuscation, given that font foundries are happy with WOFF as a better packaging for their font data, instead of raw opentype

s/... I think/AD: I think/

CL: my feedback is not to remove the obfuscation, but to reexamine that it still adds value, now that you have WOFF

JF: one more comment

<jun> http://bizpal.jp/epub/00010

JF: that screenshot is using webkit to do vertical text layout
... this uses most of the proposals of css3 vertical text/writing modes, implemented in webkit
... there's a link on that page to the source content of that webpage screenshot

<ChrisL> http://bizpal.jp/epub/ShowImage?id=32aefbb2-4626-4ec9-b0da-faa78491588f

JF: I want to encourage mozilla guys to consider supporting vertical writing in order to be used as an EPUB reading system
... to be compatible with japanese vertical writing content

CL: are any mozilla people looking at that?

RO: I think there are still some -- I can't remember what the spec stage is at, but there were some disputes about stylesheets that should affect both horizontal and vertical writing
... which quite deeply affect how you actually do it
... and I know John Daggett had some strong opinions on it

AD: a general question: is the group developing any conformance test suite?

JF: yes, they're working on it

AD: will it be publicly available?

JF: I think so, but I'm not sure
... canon is not a member of EPUB WG
... but I'm an invited expert


compositing a bit more

<anthony_nz> http://dev.w3.org/SVG/modules/compositing/master/Overview.html

AG: I've moved the text around a bit, so it follows on a bit better
... extended "object" a bit
... explained what to do to get the outline of the objects

<dholbert> " A User Agent MUST effect the pixel region as specified by the 'clip-to-self' property. " --> s/effect/affect/ I think

<ed> "The optional vaues for the new property is under consideration" --> s/vaues/values/ too

DS: if the compositing stuff is useful, is there anything svg specific about it? or should it be in css?

AD: it should be in css

DS: it'd be nicer if people who have svg or css UAs could implement it royalty free

AD: i think the porter duff modes are less useful for css content, but blend modes are very useful

SVG DOM list object identity


JW: there are various things that are unspecified in the current SVG spec
... there are a few things that implementations aren't interoperable on
... I have here a proposal for how I think it should work
... which is biased towards how we do it, but we can talk about the pros and cons of it
... one of the topics is the SVGAnimatedLengthList object
... when the SVGAnimatedLengthList object should be thrown away and replaced with a new object, such as a setAttribute call

AD: you want it to be live?

JW: that implies changes you make to it are reflected to the screen
... for the entire lifetime of the document
... to be more specific, the object is never replaced with a different object
... unless, as an optimization, the script would not be able to detect it has changed
... so if script has a reference to that object, or its animVal/baseVal, or one of the items in the lists, it wouldn't be allowed to replace the object

DH: that behaviour's not part of the spec?

JW: it's ambiguous
... currently we never throw the object away
... opera seems to throw it away in some circumstances that don't make sense to me
... webkit never throws it away
... IE always keeps the same object as well
... the only exception is opera, which sometimes throw it away

ED: seems like a bug

JW: no objections to speccing it?

ED: where would you spec it?
... i wouldn't be unhappy to go over this in SVG2, but for 1.1 it's maybe too late to make those kinds of changes

JW: but going forward?

ED: that's fine

JW: then there's the identity of the baseVal and animVal objects
... I suggest we never throw away that object if script has references to them
... same idea
... then there's the item themselves
... the way we've implemented it, we basically never throw away items from a list unless the length of the list requires items to be thrown away
... objects are just references into the list
... so if any of these 7 things happen, we still return the same object

CM: seems reasonable

ED: we should use these tests and convert them to use the new testing framework

<shepazu> http://nodelist.org/

JW: what the spec currently says, vaguely, is that if an item is inserted into a list, when it already belongs to another list, it's removed from the list it already belongs to

CM: but consistent with NodeList

JW: it depends how you conceptually see them
... are they like a js array?
... the conclusion of thinking of it like that, is to allow items in more than one list

CM: could thrown an exception

JW: it appeals to me in some way, to thrown an exception
... forces authors to be explicit

CM: i don't like copy

JW: in gecko, if the item doesn't belong to anything, it'll insert it into the list
... if it does belong to another list, it'll insert a copy
... reasoning being if you create one with createSVGLength, you probably want to edit that SVGlength object you just inserted
... the reason we copy is due to considering it to be a list, rather than a dom tree
... and it avoids confusing behaviour

[discussions about options]

(we eventually agree to throw when you try to insert an SVGLength into an SVGLengthList if that SVGLength is currently owned by anything else)

<scribe> ACTION: jwatt to write spec text about insertItem etc. throwing when the object already has an owner [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action10]

<trackbot> Created ACTION-2989 - Write spec text about insertItem etc. throwing when the object already has an owner [on Jonathan Watt - due 2011-03-09].

<dholbert> s/by anything else/by anything/

<dholbert> (including the same list)

JW: last case is mutability
... the way IE and Mozilla implement animVal lists and their items, they're read only
... while they're still in the document
... for opera and webkit, they're mutable
... you can't change the list
... the only thing i'd add, is that if an animation causes the animVal to shorten, so then animVal items are discarded from the list, then those items become mutable

ISSUE: animVal list items that are removed from their list should become mutable

<trackbot> Created ISSUE-2405 - AnimVal list items that are removed from their list should become mutable ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2405/edit .

ISSUE: Define how SVGLengths resolve % (and other) values when they are not owned by an element

<trackbot> Created ISSUE-2406 - Define how SVGLengths resolve % (and other) values when they are not owned by an element ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2406/edit .

<scribe> ACTION: Erik to review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action11]

<trackbot> Created ACTION-2990 - Review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [on Erik Dahlström - due 2011-03-09].

<scribe> ACTION: Patrick to review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action12]

<trackbot> Created ACTION-2991 - Review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [on Patrick Dengler - due 2011-03-09].

trackbot, end telcon

Summary of Action Items

[NEW] ACTION: Anthony to clarify clip-to-self behavior [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action03]
[NEW] ACTION: Anthony to fix advanced gradients spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action04]
[NEW] ACTION: Chris to contact Murata-san about an RNG schema for SVG 1.1 Second Edition [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action06]
[NEW] ACTION: Chris to mail the EPUB WG to ask whether width/height on root <svg> elements should be allowed [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action05]
[NEW] ACTION: Chris to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action09]
[NEW] ACTION: ChrisL to request puiblication of compositing spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action01]
[NEW] ACTION: Christ to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action08]
[NEW] ACTION: Doug to fix the images in the compositing spec [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action02]
[NEW] ACTION: Erik to review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action11]
[NEW] ACTION: jwatt to write spec text about insertItem etc. throwing when the object already has an owner [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action10]
[NEW] ACTION: Patrick to review http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues#Object_identity_given_indirect_changes to see if he agrees with it [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action12]
[NEW] ACTION: Talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [recorded in http://www.w3.org/2011/03/01-svg-minutes.html#action07]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/03/02 04:16:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/and reason to just/any reason to just/
Succeeded: s/TIny/Tiny/
Succeeded: s/emjoy/emoji/
FAILED: s/emojoy/emoji/
Succeeded: s/_//
Succeeded: s/engines/font engines/
FAILED: s/paste error/paste error, which I've now fixed/
Succeeded: s/ye/yes/
FAILED: s/Christ/@SVGesus/
FAILED: s/... I think/AD: I think/
Succeeded: s/we/we (mozilla)/
FAILED: s/by anything else/by anything/
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> ...
Found ScribeNick: dholbert
Found Scribe: Cameron
Found ScribeNick: heycam
ScribeNicks: dholbert, heycam
Default Present: +1.649.363.aaaa, tbah, +1.425.868.aabb
Present: +1.649.363.aaaa tbah +1.425.868.aabb
Found Date: 01 Mar 2011
Guessing minutes URL: http://www.w3.org/2011/03/01-svg-minutes.html
People with action items: anthony chris chrisl christ doug erik jwatt patrick talk

[End of scribe.perl diagnostic output]