IRC log of svg on 2011-03-01

Timestamps are in UTC.

20:12:03 [RRSAgent]
RRSAgent has joined #svg
20:12:03 [RRSAgent]
logging to http://www.w3.org/2011/03/01-svg-irc
20:12:05 [trackbot]
RRSAgent, make logs public
20:12:07 [trackbot]
Zakim, this will be GA_SVGWG
20:12:07 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
20:12:08 [trackbot]
Meeting: SVG Working Group Teleconference
20:12:08 [trackbot]
Date: 01 March 2011
20:12:12 [heycam]
Zakim, room for 4?
20:12:13 [Zakim]
ok, heycam; conference Team_(svg)20:12Z scheduled with code 26631 (CONF1) for 60 minutes until 2112Z
20:12:46 [Zakim]
Team_(svg)20:12Z has now started
20:12:53 [anthony_nz]
anthony_nz has joined #svg
20:12:53 [Zakim]
+ +1.649.363.aaaa
20:13:28 [Zakim]
+tbah
20:14:05 [birtles]
birtles has joined #svg
20:14:09 [jun]
jun has joined #svg
20:15:19 [eseidel]
eseidel has joined #svg
20:19:32 [heycam]
Chair: Cameron
20:20:19 [karl]
karl has joined #svg
20:21:06 [dholbert]
SCRIBENICK: dholbert
20:21:12 [heycam]
RRSAgent, this meeting spans midnight
20:21:50 [dholbert]
TOPIC: Compositing
20:21:57 [heycam]
Zakim, who is on the call?
20:21:57 [Zakim]
On the phone I see +1.649.363.aaaa, tbah
20:23:07 [anthony_nz]
http://dev.w3.org/SVG/modules/compositing/master/Overview.html
20:23:21 [dholbert]
AG: That has the latest version
20:23:31 [dholbert]
AG: Doug originally merged the language and the primer
20:23:51 [dholbert]
AG: It was originally in 2 parts, each property had 2 sections. I've merged it all together & added a few examples to it
20:24:06 [dholbert]
AG: I also had a few coments from people on the mailing list; addressed those
20:24:40 [dholbert]
... I also put simplified versions for the blend mode equations. Equivalent to more complicated earlier forms
20:24:58 [Zakim]
+ +1.425.868.aabb
20:25:04 [pdengler_home]
i'm in
20:26:06 [dholbert]
AG: I believe this is ready for last call for publication & we should take it to CR
20:26:21 [dholbert]
AG: Doesn't have a test suite, but the examples can be used as (to make) tests
20:27:15 [dholbert]
CM: So we've got enable-background - is that same definition as in 1.1?
20:27:30 [dholbert]
AG: No - it's different from filter enable background, if that's what you're asking
20:28:02 [dholbert]
CM: Ah, so it only applies to filters in 1.1?
20:28:34 [dholbert]
AD: This new rewording is meant to clarify that a bit
20:29:02 [dholbert]
CM: Have there been many changes since we last looked at it?
20:29:11 [dholbert]
AG: Not really - some of the equations have been tweaked
20:30:06 [jwatt]
jwatt has joined #svg
20:36:42 [dholbert]
AG: (asks AD about accumulate w/ enable-background)
20:37:22 [dholbert]
AD: The big problem w/ integrating porter-duff w/ svg enable-background accumulate is you have to do a removal step
20:38:01 [dholbert]
AD: Only matters in porter duff modes other than "over"
20:38:53 [dholbert]
AD: 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
20:38:57 [dholbert]
CM: Is that in the spec?
20:38:58 [dholbert]
AD: Yes
20:39:31 [dholbert]
AG: What about accumulate?
20:39:33 [dholbert]
AD: You only need to worry about accumulate if you're applying porter-duff to that group
20:39:45 [pdengler_home]
Is someone scribing
20:39:45 [dholbert]
CM: I'm happy for this to go to last-call
20:39:57 [dholbert]
ED: One little thing - it's normatively referencing 1.2
20:40:04 [dholbert]
CL: 1.2 tiny?
20:40:07 [pdengler_home]
pdengler_home has left #svg
20:40:08 [dholbert]
ED: No, 1.2 full
20:40:18 [dholbert]
AG: I can make that 1.1 instead
20:40:52 [dholbert]
CL: Yeah, do that
20:40:57 [pdengler_home]
pdengler_home has joined #svg
20:41:05 [shepazu]
shepazu has joined #svg
20:42:21 [dholbert]
DS: So this in itself is sufficient for anybody to do compositing?
20:43:01 [dholbert]
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
20:43:14 [dholbert]
CM: Do you have some examples of cool stuff you can do with porter duff?
20:43:32 [dholbert]
AD: Original paper has some - e.g. plus lets you smoothly blend between two videos
20:43:39 [dholbert]
CL: It'd be handy to have those sorts of examples in the spec
20:43:47 [dholbert]
AG: Can I reference Second Edition?
20:43:59 [dholbert]
CL: Yes, you can't not do that
20:44:01 [heycam]
RRSAgent, pointer?
20:44:01 [RRSAgent]
See http://www.w3.org/2011/03/01-svg-irc#T20-44-01
20:44:46 [dholbert]
CL: In the references section, it mentions PDF, but that's not actually used/cited anywhere
20:44:58 [dholbert]
CM: Actually none of those references are used/cited anywhere
20:45:11 [dholbert]
AG: Yeah, I should go through that
20:45:41 [dholbert]
CM: Do you know if the spec builds properly?
20:45:50 [dholbert]
AG: Yes, I think we got that working
20:45:55 [ChrisL]
ChrisL has joined #svg
20:46:02 [AD]
AD has joined #svg
20:46:06 [dholbert]
AG: So with the references ...
20:46:16 [dholbert]
CM: If you're going to have a normative reference, it'd be SVG 1.1
20:46:37 [dholbert]
CM: If you wanted to include an explicit actual reference/citation in the spec, just do it the first time you mention SVG
20:47:25 [dholbert]
RESOLUTION: Move compositing spec to last-call, after references have been fixed
20:47:47 [dholbert]
DS: There's a couple of things you'll need to fix in the images - some are missing xlink:href namespace decl
20:47:54 [ChrisL]
ACTION: ChrisL to request puiblication of compositing spec
20:47:55 [trackbot]
Created ACTION-2982 - Request puiblication of compositing spec [on Chris Lilley - due 2011-03-08].
20:48:27 [dholbert]
DS: Also, some of the images are using a raster as the background, and when it blows up, it looks really bad.
20:48:37 [dholbert]
DS: I'll make a SVG version of that background that you can use
20:48:56 [dholbert]
ACTION: Doug to fix the images in the compositing spec
20:48:57 [trackbot]
Created ACTION-2983 - Fix the images in the compositing spec [on Doug Schepers - due 2011-03-08].
20:49:38 [dholbert]
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
20:50:05 [dholbert]
CL: That's good if it's using SVG 1.1, but if it's using something newer...
20:50:24 [dholbert]
DS: for newer features, we can make a mockup using SVG 1.1
20:50:35 [dholbert]
CM: Might have to use a PNG for mocking up some things
20:50:44 [dholbert]
DS: Sure, we can do that if we need to
20:51:27 [Zakim]
- +1.425.868.aabb
20:52:22 [roc]
roc has joined #svg
20:53:36 [dholbert]
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
20:53:58 [dholbert]
CL: Can't you calculate how far out you'd need?
20:54:19 [dholbert]
RO: You can, but some filter primitives require that you'd draw the whole background
20:54:37 [dholbert]
RO: Normally the natural thing to do is to clip to the viewport at the beginning
20:54:51 [dholbert]
... it's possible to have things that are infinite in extent, like a tiled CSS background
20:55:21 [dholbert]
... so no one has implemented it correctly yet, so it's not clear that it's implementable
20:55:28 [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 )
20:56:06 [dholbert]
AG: w/ references - did we write a requirements doc for compositing?
20:56:22 [dholbert]
CL: Normally you don't need to reference that from within the spec
20:57:25 [dholbert]
AG: I'll work on those references today and have it ready by next week
20:57:43 [dholbert]
DS: Can you fix those xlink:href's too? and I'll work on the background thing
20:58:00 [Zakim]
-tbah
20:58:47 [Zakim]
+tbah
20:59:47 [dholbert]
RO: Ah, so the issue that I talked about w/ clipping doesn't come up with this spec. But do we need enable-background?
21:00:33 [dholbert]
AS: So the standard blending modes are just using alpha compositing - don't need to worry about enable-background for those
21:00:36 [dholbert]
*AD
21:01:04 [dholbert]
AD: ... but with the more complex ones, it's important
21:01:24 [dholbert]
RO: So with the new rectangle thing, do we need that, or can we infer that?
21:01:40 [dholbert]
RO: We can probably optimize that automatically
21:02:07 [dholbert]
AG: It's an implementation hit, and I'd put it in because someone requested it
21:02:30 [dholbert]
CL: Let's keep it in the spec, but later add a comment saying that it's not mandatory and can be dropped
21:02:41 [dholbert]
... for last-call
21:03:10 [dholbert]
RO: It adds extra work for us to do that clipping, when it's not always necessary/useful
21:04:01 [dholbert]
RO: In the clip-to-self property, it talks about whether you use bounded vs unbounded operators
21:04:25 [dholbert]
... 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?
21:04:56 [dholbert]
... so if it's dashed with opacity 0, do we consider that part of the shape of the object?
21:05:15 [dholbert]
CM: If it's fill:none, it wouldn't be included, but if it's opacity 0, it would
21:05:30 [dholbert]
AD: This is partly for compatibility with Java 2D
21:05:40 [dholbert]
RO: We had similar issues with canvas
21:06:01 [dholbert]
RO: I think this needs to be clarified - all these edge cases, whether pixels are affected or not
21:06:16 [dholbert]
AD: yeah, which pixels have been 'touched'
21:06:24 [dholbert]
RO: We need to define what 'touched' pixels means
21:07:05 [dholbert]
CM: spec says -- "for filled and stroked shapes and text, the object is directly converted to a clipping path"
21:07:17 [dholbert]
CM: Perhaps that means 'if you stuck it in a <clipPath>'?
21:07:27 [dholbert]
CL: No, it's clipped as if it _was_ a clipping path
21:08:17 [dholbert]
ACTION: Anthony to clarify clip-to-self behavior
21:08:17 [trackbot]
Created ACTION-2984 - Clarify clip-to-self behavior [on Anthony Grasso - due 2011-03-08].
21:08:39 [dholbert]
RO: I think it'd be useful if it matched clipPath behavior
21:08:56 [dholbert]
AD: but clip-to-self works with antialiased edges
21:09:18 [dholbert]
RO: We can say the shape is the same, but the edges are up to the implementation
21:09:50 [dholbert]
CL: We shouldn't use wording that suggests that anything magical happens with an anonymous <clipPath> under the hood
21:10:15 [dholbert]
CM: Maybe we should express it in terms of a mask instead?
21:10:55 [dholbert]
AG: so it's just 'whatever pixels are painted'?
21:11:03 [dholbert]
RO: That's still not entirely clear
21:11:45 [dholbert]
RO: It has to be precise, but we shouldn't so much suggest how to implement it
21:11:56 [dholbert]
AG: So are we still happy to publish, then?
21:12:15 [dholbert]
CM: So we've got note about enable-background new, the references, clip-to-self -- is that all that's required?
21:14:02 [dholbert]
RO: So we don't leave last-call until there are 2 implementations & tests?
21:14:13 [dholbert]
DS: No, candidate-recommendation is where that happens
21:14:41 [dholbert]
DS: (and you might go back to last-call after being in CR)
21:15:48 [dholbert]
topic: Advanced Gradients
21:16:21 [anthony_nz]
http://www.w3.org/Graphics/SVG/WG/wiki/images/f/fc/SVG_Advanced_Gradients_Requirements.pdf
21:16:25 [dholbert]
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
21:16:38 [dholbert]
AG: I drafted some use-cases & requirements for some advanced gradient feature
21:16:52 [dholbert]
AG: I think SVG 2 would look a bit poor with just the basic gradients that we have
21:17:01 [dholbert]
CM: Given how often people have been asking for advanced gradients
21:17:21 [dholbert]
AG: I've left the draft pretty open-ended in terms of focusing on specific tech
21:17:43 [dholbert]
AG: Some of the input that went into this came directly from authors & usability specialists - the people who actually do the drawing
21:17:53 [eseidel]
eseidel has joined #svg
21:17:56 [dholbert]
AG: I haven't committed it yet since I don't really know where to stick it
21:18:37 [dholbert]
AG: (The wiki wouldn't let me upload an HTML document, so that's why it's a PDF right now.)
21:21:26 [Alex]
Alex has joined #svg
21:21:42 [dholbert]
AG: (puts spec on projector)
21:22:15 [dholbert]
AG: The first part is just boilerplate. The bits that are different from the template are the introduction...
21:22:28 [dholbert]
... So 'usage scenarios' is the first bit that I added.
21:22:40 [dholbert]
CM: So are these what your designers said they wanted?
21:23:05 [dholbert]
AG: Yeah - they wanted to be able to produce naturalistic images in a pretty simple way, with a compact representation
21:23:31 [dholbert]
... they're used to it in photoshop, where it works but is difficult to lay down all the mesh points
21:23:54 [dholbert]
... They want something between that and what they can do in illustrator.
21:24:10 [dholbert]
DS: Would be nice to somehow combine gradients
21:24:37 [dholbert]
AD: Tav had some demo page. I had to implement some of that and it was quite hard
21:25:38 [tbah]
http://tavmjong.free.fr/SVG/MESH/Mesh.html
21:25:41 [dholbert]
... 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
21:25:57 [dholbert]
DS: suboptimal from an author's point of view
21:26:23 [dholbert]
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
21:28:08 [dholbert]
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
21:28:22 [dholbert]
DS: So it's non-trivial to author?
21:28:31 [dholbert]
AD: It's trivial with authoring tools like Maya, etc
21:28:47 [dholbert]
AG: But what about hand-authoring to tweak something?
21:29:12 [dholbert]
CM: What about animating it?
21:29:21 [dholbert]
AD: If you define the syntax right, it wouldn't be too hard
21:29:48 [dholbert]
AD: Making the object move might be tricky - but making it look like the light is moving would be trivial (by animating the normals)
21:30:07 [dholbert]
CM: Can you do that with filters, too?
21:30:33 [dholbert]
AD: Yeah
21:30:51 [dholbert]
AG: So -- I put a few examples in there of the usage scenarios
21:31:43 [dholbert]
AG: (opens an artistic effect demo) At the moment, to do this in SVG is nontrivial / impossible
21:32:08 [dholbert]
CM: Do you have a summary of tools & which kinds of gradients they can do?
21:32:14 [dholbert]
AG: No, not yet
21:32:32 [dholbert]
CM: If mesh gradients are tricky, they might still be worth it if people are familiar with them
21:34:04 [dholbert]
AG: (scrolls to 'special considerations for advanced gradients')
21:34:15 [dholbert]
AG: So there's a section for memory & processor requirements
21:34:51 [dholbert]
DS: We should ask other authoring tool companies what they think about this
21:35:11 [dholbert]
ED: Scribus has mesh gradients, and they export SVG, but I don't know what syntax they use
21:35:51 [dholbert]
TB: Now that Cairo has support for mesh gradients, there's a lot of interest in them
21:36:38 [dholbert]
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?
21:36:45 [dholbert]
TB: Sure, you can take anything you want
21:36:57 [dholbert]
AG: Yeah, it'd be nice to just take that research and put it into a W3C document
21:37:34 [dholbert]
DS: In a Google-search for cairo gradient mesh, the fifth link is Tav's document
21:37:44 [dholbert]
TB: mm hm
21:38:12 [dholbert]
CM: Anyone know if other graphics libraries like CoreGraphics have advanced gradient support?
21:38:23 [AlexD]
AlexD has joined #svg
21:38:36 [dholbert]
DS: So it sounds like gradient meshes are certainly of interest - regardless of what else we do, we should probably have gradient meshes
21:39:09 [dholbert]
AG: One of the things designers want is to control how far color spreads out from a point
21:39:20 [dholbert]
DS: More like an ellipse or like a circle?
21:39:41 [dholbert]
CM: so normal gradient meshes do color interpolation between the three points
21:40:14 [dholbert]
TB: tensor meshes have extra control points - that is implemented by cairo
21:40:28 [dholbert]
DS: We should talk to the cairo guys
21:40:35 [dholbert]
RO: We can look at the code & documentation
21:40:49 [dholbert]
AG: I added animatability as one of the requirements
21:41:22 [dholbert]
AG: Also, 'syntax can be easily authored by hand', or at least easily understood by authors
21:41:52 [dholbert]
AG: also, I added a requirement that we maintain compatibility with CSS where possible
21:42:10 [dholbert]
DS: They'll likely follow whatever this spec does
21:42:27 [ChrisL]
A new CAD mesh segmentation method, based on curvature tensor analysis
21:42:28 [dholbert]
DS: There was an action on Tav to talk to Tab Atkins
21:42:29 [ChrisL]
Computer-Aided Design
21:42:29 [ChrisL]
Volume 37, Issue 10, 1 September 2005, Pages 975-987
21:42:36 [dholbert]
TB: Haven't done that yet
21:42:38 [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
21:42:52 [dholbert]
CM: Easily authoring by hand will be tricky - even authoring paths by hand is difficult
21:43:19 [dholbert]
AG: I meant more that it's easy to follow. With paths, you can look at it and see "cubic bezier, etc".
21:43:30 [dholbert]
CM: Ah, yeah - so just 'not a binary blob' I guess
21:43:34 [Zakim]
-tbah
21:43:47 [dholbert]
DS: So RE animation -- the gradient itself must be animatable, I guess
21:44:00 [dholbert]
BB: So what about diffusion curves?
21:44:33 [dholbert]
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
21:44:43 [dholbert]
... and they'd like to make it so only one side will diffuse
21:44:48 [tbah]
I just got cutoff and the access code is "restricted" at this time.
21:45:00 [dholbert]
... so it has things they like, but they have issues with it
21:45:11 [roc]
shepazu: cairo's "mesh patterns": http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c#n801
21:45:17 [Zakim]
- +1.649.363.aaaa
21:45:19 [Zakim]
Team_(svg)20:12Z has ended
21:45:21 [Zakim]
Attendees were +1.649.363.aaaa, tbah, +1.425.868.aabb
21:45:54 [dholbert]
(break)
21:46:26 [tbah]
OK, I'll probably just head off to lala land. Thanks.
22:14:22 [dholbert]
AG: so I'll make the suggested changes, and then we can publish at some point
22:14:51 [dholbert]
ACTION: Anthony to fix advanced gradients spec
22:14:51 [trackbot]
Created ACTION-2985 - Fix advanced gradients spec [on Anthony Grasso - due 2011-03-08].
22:15:46 [heycam]
Scribe: Cameron
22:15:53 [heycam]
ScribeNick: heycam
22:15:56 [heycam]
Topic: WOFF in SVG 2
22:16:15 [heycam]
CL: [summarises history of downloadable fonts]
22:19:27 [AD]
AD has joined #svg
22:20:32 [heycam]
... [summarises why SVG fonts were devised, and what WOFF does]
22:20:55 [heycam]
... so coming into SVG 2 we have WOFF which is everywhere now
22:21:02 [heycam]
... we can do nicer things in svg now that we have this font format
22:21:09 [heycam]
... it's way better internationalized than svg fonts
22:21:22 [heycam]
... i looked at using graphite with svg fonts, but there'd be a lot of work for that
22:21:29 [heycam]
... and it's not the direction the industry is going
22:21:36 [heycam]
... so my proposal is to mandate woff in svg 2
22:22:45 [heycam]
... i'd like to see it in batik
22:23:03 [heycam]
... it's already in firefox since 3.6, and opera since 11.1 or so
22:23:09 [heycam]
... in ie9 since preview 2
22:23:41 [heycam]
... the only format that mobile safari used to support was svg fonts
22:23:49 [heycam]
... which is why fontsquirrel etc. output svg fonts
22:23:57 [heycam]
... i believe the new mobile safari supports woff
22:24:13 [heycam]
ED: are there any other formats that should be mandated? and reason to just require woff?
22:24:22 [heycam]
CL: if you've got a ttf/otf font you can convert it to woff easily
22:24:35 [heycam]
... some browsers support linking to native ttf/otf, some don't
22:24:43 [heycam]
... most of hte font vendors hate the idea of link to tt/otf
22:24:52 [heycam]
... even though they know it's trivial to convert between them and woff
22:25:09 [heycam]
... it's the difference between picking up a wallet on the street, and taking it out of a car
22:25:26 [heycam]
... we've been careful in the fonts wg to not require any browser enforcement
22:25:51 [ed]
s/and reason to just/any reason to just/
22:26:04 [heycam]
... so the font guys are happy to license fonts for desktop (otf) or the same font in woff for online
22:26:18 [heycam]
... it's a big deal. there's a whole new font industry now.
22:26:25 [heycam]
... and the free font industry too, the open font library
22:26:42 [heycam]
... if we require it that you're linking to raw otf then it's going to ruffle a lot of feathers
22:26:59 [heycam]
RO: ie9 does allow linking to raw ttf fonts, if they've got the correct permissions bits set
22:27:14 [heycam]
CL: right, and also enforces a same origin restriction
22:27:29 [heycam]
DS: but nobody objects to requiring woff?
22:27:39 [heycam]
(no)
22:28:00 [heycam]
JF: what is the current status with html5 and woff?
22:28:08 [heycam]
CL: html5 doesn't mention woff, because it doesn't talk about formatting as such
22:28:13 [heycam]
... it's css that talks about formatting
22:28:25 [heycam]
... currently it's completely separate. the css3-fonts spec which says how to link to fonts.
22:28:37 [heycam]
... the woff spec references css3-fonts, but there's no requirement in css3 to support woff
22:28:54 [heycam]
JF: you are suggesting svg2 to reference directly to woff, not just css3-fonts?
22:29:01 [heycam]
CL: right, because css3-fonts doesn't require any particular font format
22:29:10 [karl]
karl has joined #svg
22:29:14 [heycam]
... if that requirement moved to css3-fonts, we wouldn't need to have it in our spec
22:29:23 [heycam]
... for the moment i think it makes sense to put it in there
22:29:29 [heycam]
... we can take it out later if css3-fonts starts to require woff
22:29:40 [heycam]
... we should also link to css3-fonts instead of css3 in svg2
22:29:47 [heycam]
... which also gets us the cool new features
22:30:28 [heycam]
JF: if we mandate the use of woff in svg, does that mean html5 implementations also need to support woff?
22:30:33 [heycam]
DS: svg support is not required by html5
22:30:42 [heycam]
... but an html5 & svg user agent would be required to
22:30:56 [heycam]
CL: the implementaitons of html5 already have woff support, mostly
22:31:12 [heycam]
JF: i'm just wondering if we should align with html5
22:31:32 [heycam]
CL: we can suggest that html5 requires that, but i suspect it won't, because it's css's job to do the rendering
22:31:38 [heycam]
... but i notice that epub3 requires woff
22:32:01 [heycam]
RESOLUTION: We will mandate WOFF support in SVG 2.
22:32:14 [heycam]
AD: should we consider being able to encode it inline just like in svg fonts?
22:32:20 [heycam]
... so we can have self contained files with font data?
22:32:25 [heycam]
... that's a major benefit of svg fonts
22:32:31 [heycam]
CL: something other than using a data uri?
22:32:40 [heycam]
AD: something like data uri
22:32:47 [heycam]
CL: yes that would already work
22:33:19 [heycam]
RO: how abotu the size of a woff font compared to an svg font?
22:33:32 [heycam]
CL: svg fonts have not much overhead, once gzipped is reasonable
22:33:49 [heycam]
RO: MB-sized data uris work fine in gecko
22:34:15 [heycam]
AD: it's be nice to have a better encoding for data uris
22:34:27 [heycam]
CL: that's a general thing for binary stuff, xml isn't very good at including binary stuff
22:34:39 [heycam]
AD: base64 was designed in an old era that doesn't really apply
22:34:56 [heycam]
... for an era when you only had 6 guaranteed bits
22:35:13 [heycam]
DS: just write an rfc for it
22:35:42 [heycam]
CL: you could an extra encoding, other than ",base64" to data uris
22:35:49 [heycam]
AD: base64 decoding is slow
22:35:59 [heycam]
... if the encoding was simpler...
22:36:07 [heycam]
... so something similar to base64 but using more bits
22:36:25 [heycam]
... base64 requires a lot of bit shifting
22:37:47 [heycam]
CL: feel free to have at it. it's not for this wg to do, though.
22:38:51 [heycam]
Topic: SVG Fonts
22:38:57 [heycam]
ED: i wrote up a short page
22:39:03 [heycam]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVG_Fonts
22:39:19 [heycam]
... this will require SVG 1.2 Tiny Fonts for SVG 2, but to leave out the complex fonts for a separate module
22:39:35 [heycam]
AD: i think that's a sensible thing, since so many devices already implement 1.2T SVG Fonts
22:39:51 [heycam]
ED: SVG Tiny 1.1 defined it too
22:39:55 [heycam]
... but better defined in 1.2T
22:40:05 [heycam]
CL: the tiny fonts are simpler, you don't have any content as a glyph
22:40:25 [heycam]
... so all the cool stuff you can't do in opentype, you can't do in Tiny SVG Fonts
22:40:30 [heycam]
... but you can build it on the fly with script
22:41:26 [heycam]
... some things tiny svg fonts can do that opentype can't do
22:41:51 [heycam]
... various path shapes aren't allowed in opentype, like self-intersecting curves, and many requirements on curve control point positions
22:41:57 [heycam]
BB: is that an extra feature?
22:42:06 [heycam]
DS: it's ease of use
22:42:26 [heycam]
CL: it's extra stuff that you have to do with an opentype font
22:42:36 [heycam]
... you can mix cubic/quadratic curves in the same glyph, whatever you want
22:42:49 [heycam]
... producing something on the fly, or draw a handwriting font, is more tractable using svg fonts
22:43:44 [heycam]
ED: altGlyph isn't part of TIny fonts
22:43:47 [heycam]
s/TIny/Tiny/
22:43:58 [heycam]
DS: i think we should be looking at a variety of possible options for SVG2
22:44:11 [heycam]
... one of them is allowing a <glyph> to be inline, so it doesn't have to be associated with a font parent
22:44:17 [heycam]
... could just be a glyph inline
22:45:13 [homata_]
homata_ has joined #svg
22:48:56 [heycam]
(some discussion about y-up coordinate systems)
22:50:42 [heycam]
BB: i want to know what we get by requiring 1.2T fonts in SVG2
22:50:50 [heycam]
... so we get access to the path data, and it's easier to author
22:50:56 [heycam]
DS: and also it's embedded in one file
22:51:06 [heycam]
BB: which you can already do with data uris
22:52:22 [heycam]
AD: there are 100s of millions of devices with Tiny fonts out there
22:52:35 [heycam]
... and there's lots of content on mobile that supports it. all the ipad stuff is using Tiny fonts.
22:52:38 [ChrisL]
data uri kitchen http://software.hixie.ch/utilities/cgi/data/data
22:52:53 [heycam]
BB: by the time svg2 out those devices will have woff support
22:52:59 [heycam]
AD: it's a backward compatibility thing
22:53:25 [heycam]
... you can write some script to modify the font on the fly
22:53:41 [heycam]
CL: another concrete benefit is that it's already widely implemented on some desktop platforms, and almost all mobile platforms
22:53:44 [heycam]
BB: so backwards compat
22:53:49 [heycam]
DS: authoring tools too
22:54:13 [heycam]
AD: corel draw e.g., you can click export and it will subset system fonts and turn them into svg fonts
22:54:19 [heycam]
CL: since corel draw 8
22:54:25 [heycam]
CM: inkscape can generate svg fonts too
22:54:38 [heycam]
DS: it's fairly lightweight, not particularly difficult to implement
22:54:48 [heycam]
... there are lots of tools that already do it, it solves some use cases that woff doesn't, why not do it?
22:55:07 [heycam]
JF: i'd like to talk about use cases in the japanese market
22:55:16 [heycam]
... in the epub wg we talked a lot about the use of svg fonts and woff fonts
22:55:22 [heycam]
... we found important use cases for svg fonts
22:55:30 [heycam]
... the first is to use svg fonts to support emjoy characters
22:55:36 [heycam]
s/emjoy/emoji/
22:55:43 [ChrisL]
s/emojoy/emoji/
22:55:47 [heycam]
... which are part of unicdode 6.0
22:55:52 [heycam]
... they can be animated
22:56:08 [heycam]
... opentype cannot support emoji characters, but svg fonts can
22:56:34 [heycam]
... emoji is very important for japanese, since there are many mobiles targetted towards keitai users
22:56:42 [heycam]
RO: but that's full fonts, not tiny fonts?
22:56:47 [heycam]
JF: yes
22:57:06 [heycam]
... the other use case includes in japan we need to support variation characters
22:57:23 [heycam]
... the current implementation of browsers and ereading systems does not support IVS yet
22:57:41 [heycam]
... but that's easy with svg fonts. you can easily define variation characters using the svg font mechiansm.
22:58:00 [heycam]
... you can just use the variation selector, so that text content is a proper unicode sequence
22:58:08 [heycam]
... you can use svg font defined variation characters
22:58:19 [heycam]
BB: for emoji, is that a bounded set?
22:58:20 [heycam]
JF: yes
22:58:31 [heycam]
BB: do you ever have e.g. novels where they want to use a new character that's not in the set?
22:59:46 [heycam]
JF: also there can be one or two special characters in a novel that are not covered in unicode
22:59:55 [heycam]
BB: with the unicode variant, is this a backwards compat issue?
23:00:03 [heycam]
... i believe in firefox we allow variants to be selected from fonts
23:00:11 [heycam]
RO: why wouldn't the variant selectors work with opentype?
23:00:35 [heycam]
JF: because some leading systems, their OSes don't support variation selectors
23:00:41 [heycam]
... and it's sometimes difficult to implement on those systems
23:01:03 [heycam]
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?
23:01:05 [heycam]
JF: yeah
23:01:11 [heycam]
... it's a kind of lightweight workaround
23:01:27 [heycam]
BB: with the emoji, if there are new ones publishers want to use, it sounds like we need another feature
23:01:43 [heycam]
JF: we think that is not that important, and it can just be a user defined feature
23:10:51 [heycam]
CM: (shows some examples on the board)_
23:10:53 [heycam]
s/_//
23:13:14 [heycam]
JF: i have one suggestion for svg fonts
23:13:28 [heycam]
... fonts in tiny do not support vertical alignment
23:13:48 [heycam]
... we'd like to see that supported by svg fonts in svg2
23:14:06 [heycam]
CL: i'm hearing a proposal that it should be tiny fonts as implemented, but possible with alyGlyph and adding the vertical stuff
23:14:29 [heycam]
... i think we may have removed vertical font support because vertical text wasn't supported in tiny
23:14:38 [heycam]
AD: the people doing the tiny font subset weren't interested in vertical text
23:14:52 [heycam]
ED: opera has the horiz-adv-y for svg fonts as well
23:14:55 [heycam]
... it's a small addition
23:15:20 [heycam]
DS: the proposal is svg2 includes that starts with 1.2T SVG Fonts with a couple of additions
23:15:44 [heycam]
ED: and dividing it in to an optional module for svg full fonts
23:15:57 [heycam]
DS: pushback?
23:16:05 [heycam]
BB: i just want to be clear what the benefits are
23:16:20 [heycam]
... we should be arguing why we need it, not why not
23:16:24 [heycam]
DS: there are arguments from both sides
23:16:42 [heycam]
RO: i have a question
23:16:54 [heycam]
... one that i'd like to understand is...
23:17:02 [heycam]
... let's assume there are good use cases supported by tiny fonts
23:17:14 [heycam]
... we know that we basic or nonexistent shaping in tiny fonts
23:17:27 [heycam]
... i assume these use cases are also valid use cases in the context of indic characters, which require complex shaping
23:17:33 [heycam]
... what's the plan to support those use cases in those languages?
23:17:43 [heycam]
... i think we need a plan, a story to tell -- how we'll support those use cases on the web
23:17:49 [heycam]
... we don't want to say we just won't support those scripts
23:18:02 [heycam]
... does it mean extend fonts to handle those scripts, or handling these use cases with a differently technology?
23:18:32 [heycam]
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?
23:18:43 [ed]
i would say tiny12 has basic shaping support, with arabic-form, so it's not nonexistent
23:18:45 [heycam]
... started taking about svg thing, but moved on to not necessarily needing to be
23:18:56 [heycam]
... that discussion i think should happen outside the svg wg
23:19:01 [heycam]
AD: you're spot on with the shaping stuff
23:19:10 [heycam]
... it's effectively programmatic
23:19:25 [heycam]
... the support for arabic in svg full fonts is pretty basic compared to what engines can do
23:19:28 [heycam]
s/engines/font engines/
23:19:42 [heycam]
... you virtually need a programming lgnauge in the font to do the shaping
23:19:53 [heycam]
RO: opentype does support shaping for indic
23:19:59 [heycam]
... it's a lot of custom logic in the font engine
23:20:10 [heycam]
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
23:20:19 [heycam]
RO: in practice everyone need to implement this for opentype shaping
23:20:29 [heycam]
... and there are open source ones like harfbuzz
23:20:51 [heycam]
... where i'm going is, are you guys saying that there'll be some new font tech that will solve it?
23:20:52 [heycam]
AD: no
23:21:05 [heycam]
... i think there are specialists in fonts/shaping who would be better to ask about future font techs
23:21:23 [heycam]
RO: if we extend svg fonts with advanced shaping to handle indic etc. we could say that's what we think will happen.
23:21:49 [heycam]
... 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
23:22:00 [heycam]
AD: company logos e.g. is a different kind of use case
23:22:56 [heycam]
... it needs to be accessible
23:23:02 [heycam]
RO: i'd like to have an answer to that question
23:23:05 [heycam]
AD: for the longer future?
23:23:11 [heycam]
... when we're talking about tiny
23:25:05 [heycam]
[...]
23:27:09 [heycam]
CL: [talks about investigating graphite-like support for svg fonts]
00:19:28 [roc]
roc has joined #svg
00:21:48 [jun]
jun has joined #svg
00:25:39 [birtles]
birtles has joined #svg
00:40:31 [heycam]
trackbot, close ACTION-2939
00:40:31 [trackbot]
ACTION-2939 Look into batik failing filters-overview-01 closed
00:46:42 [anthony_]
anthony_ has joined #svg
00:47:01 [anthony_nz]
anthony_nz has joined #svg
00:47:14 [heycam]
RESOLUTION: SVG 2 will mandate support for SVG Tiny fonts support, and SVG Full fonts will be specified in a separate module.
00:48:44 [ChrisL]
ChrisL has joined #svg
00:50:21 [heycam]
Topic: SVG IG Japan report
00:50:30 [heycam]
JF: first i'll talk a bit about SVG IG Japan
00:50:45 [heycam]
... SVG IG Japan, we started the activity two years ago
00:50:52 [heycam]
... core members consist of 8-10 people
00:50:58 [heycam]
... mainly interested in SVG for mapping
00:51:11 [heycam]
... we've had 7 f2f meetings int he past two years
00:51:19 [heycam]
... total number of people who have attended these meetings is over 20
00:51:32 [heycam]
... we invite guest speakers from, for example, google japan
00:51:35 [heycam]
... or from mozilla tokyo
00:51:49 [heycam]
... also w3c people like doug, who attended the first f2f meeting
00:52:06 [heycam]
... the main topic of discussion in SVG IG Japan has been SVG JIS standardisation
00:52:10 [heycam]
... and SVG extensions for mapping
00:52:17 [heycam]
... these are the two main topics we discuss
00:52:28 [heycam]
... there is an effort to make an SVG JIS standard in japan
00:52:41 [heycam]
... there have been three committees for standardising SVG
00:52:54 [heycam]
... the first committee translated the draft specification of SVG 1.2 Tiny, about three years ago
00:52:57 [AD]
AD has joined #svg
00:53:17 [heycam]
... then the second committee created a new SVG extension for mapping, that was in 2009/2010
00:54:00 [heycam]
... we 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
00:54:14 [heycam]
... we have applied to have two official JIS standards: one for 1.2T, one for the mapping extensions
00:54:36 [heycam]
... we are currently working on the final stage of review, and we will finish this third phase of the committee by next March
00:55:08 [heycam]
... so you can expect to get these two JIS standards published some time before 2013
00:55:24 [heycam]
CL: once something has become a JIS standard, a few years later it's elegible to become an ISO standard, is taht right?
00:55:42 [heycam]
JF: three years ago we did the translation of 1.2T, and that's just a TS -- technical specification
00:55:45 [heycam]
... that's not an official JIS standard
00:55:56 [heycam]
... our goal now is to publish the official JIS standard, some time in 2012 or 2013
00:56:02 [heycam]
... that work will be finished by march
00:56:15 [heycam]
CL: the mapping extensions was started in 2009, is that dervied from the KDDI extensions?
00:56:17 [heycam]
JF: yes, exactly
00:56:39 [heycam]
... in the last two years we tried to align JIS SVG extensions and W3C/SVG specificaiton
00:56:51 [heycam]
... that was the reason why we proposed to create the new module SVG Tiling & Layers
00:57:06 [heycam]
CL: this is in japanese. will there be an english translation of the mapping part?
00:57:08 [heycam]
JF: yes
00:57:20 [heycam]
AD: there's an english description on the web
00:57:29 [heycam]
... and I've got a demo of a Tiling implementation
00:57:59 [heycam]
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?
00:58:00 [heycam]
JF: yes
00:58:06 [heycam]
... they decided to join W3C
00:58:11 [heycam]
... also they are very interested in joining the SVG WG
00:58:20 [heycam]
... to work on the SVG TIling & Layering specification
00:58:23 [heycam]
... that's their intention
00:58:31 [heycam]
CL: that's good news they're rejoining
00:58:43 [heycam]
... we want to understand the original principles, so that we don't accidentally change things they need
00:58:53 [heycam]
DS: you think 2012-13 is when you'll complete that part of the JIS standard as well?
00:58:55 [heycam]
JS: yes
00:59:13 [heycam]
... but ths SVG JIS committee to work on that standard will be finished in March
00:59:20 [heycam]
DS: maybe version 2 could have some changes?
00:59:21 [heycam]
JF: yes
00:59:30 [heycam]
... at first, we may start with two different specifications
00:59:50 [heycam]
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
01:00:00 [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
01:00:06 [heycam]
... and I talked to them about tiling and layering, and it's exactly what they're interested in, from a different perspective than mapping
01:00:35 [heycam]
... KDDI is also interested in HTML5 and TV on Web, from some other people
01:01:10 [heycam]
... 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
01:01:18 [heycam]
... I have a draft charter for that
01:01:54 [shepazu]
shepazu has joined #svg
01:02:54 [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
01:03:28 [heycam]
http://www.w3.org/Graphics/SVG/map/map-charter.html
01:03:56 [shepazu]
12http://www.w3.org/Graphics/SVG/map/map-charter.html
01:03:59 [shepazu]
12http://www.w3.org/Graphics/SVG/map/map-charter.html
01:04:01 [shepazu]
12http://www.w3.org/Graphics/SVG/map/map-charter.html
01:04:03 [shepazu]
12test
01:04:07 [shepazu]
shepazu has left #svg
01:04:08 [shepazu]
shepazu has joined #svg
01:05:42 [heycam]
DS: it's not formal
01:06:04 [heycam]
... I'm open to suggestions
01:06:27 [heycam]
... 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
01:06:50 [heycam]
AD: for example the tiling module, we did stuff for 1.2F, multi image resolution
01:07:04 [heycam]
... some of the KDDI datasets are like 5GB of map data
01:07:12 [heycam]
... but you can navigate it effectively with those kinds of extensions
01:07:59 [heycam]
DS: what is the implementation burden?
01:08:01 [heycam]
AD: it's not a lot
01:08:23 [heycam]
... the root container has a mapping from whatever coordinates space, WGS84
01:08:51 [heycam]
... when you load the child SVG content, it can be whatever it is, as long as it declares its mapping to WGS84
01:09:06 [heycam]
... the globalCoordinateSystem element is a sibling of the graphics, rather than a parent of the graphics, for some reason
01:09:10 [heycam]
... that's a bit of a mistake in the design
01:09:21 [heycam]
... it means that anyone that implements a standard graphics state stack to affect all the siblings
01:09:50 [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
01:10:03 [heycam]
CL: the way W3C did was to have a child <metadata> element with the mapping information in it
01:10:07 [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."
01:10:23 [heycam]
AD: the early prototypes used the rdf stuff
01:10:33 [heycam]
... then they decided they wanted a first class citizen element
01:10:42 [heycam]
CL: is this how it's specified in the JIS standard?
01:10:43 [heycam]
AD: yes
01:10:51 [heycam]
CL: has it shipped in implementations?
01:10:53 [heycam]
AD: probably not
01:10:56 [heycam]
CL: can we change it?
01:11:00 [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
01:11:03 [heycam]
... what timeline is there?
01:11:14 [heycam]
JF: I'm not sure, the JIS standard is in the very last stage
01:11:16 [roc]
ed: but Opera and Batik treat them differently I guess
01:11:25 [heycam]
DS: it's going to mean content is not compatible, but it's not a big change
01:11:34 [heycam]
... and there will probably be other changes as well
01:11:48 [heycam]
CL: ISO has an errata process, corrigenda
01:11:53 [heycam]
... I assume that JIS also has such a process?
01:11:54 [heycam]
JF: yes
01:11:58 [heycam]
CL: we could put in feedback that way
01:12:08 [heycam]
... 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
01:12:12 [heycam]
... but after, it's annoying
01:12:25 [heycam]
AD: this only applies to geographic transforms, nothing to do with tiling & layering
01:13:26 [heycam]
JF: I suggest to make a suggestion to Tagaki-san
01:13:39 [heycam]
AD: I've spoken to him about these changes, and the feedback he's given me is that they welcome what W3C suggests
01:14:17 [heycam]
... they also use ref() transforms from 1.2T, and they modifieid it to interact with the geographic transforms
01:14:20 [heycam]
... and that's not defined
01:14:24 [heycam]
CL: we can fix these things up
01:14:47 [heycam]
AD: I don't think they'd have a problem with converting the map data they already have
01:15:00 [heycam]
DS: to what degree is this client side, and what server?
01:15:10 [heycam]
AD: the server is responsible for producing all of the tiles
01:15:17 [heycam]
CL: the benefit is that you can connect to multiple servers
01:15:31 [heycam]
AD: one of the examples I've got is where they generate tiles from open street map
01:15:36 [heycam]
... from two different places
01:15:55 [heycam]
RO: should web browsers be able to display raw map data?
01:16:07 [heycam]
... all the mapping applications I currently see have interfaces that let you search, and apply overalys
01:16:10 [heycam]
... they're all using script
01:16:21 [heycam]
... is it something we really need to display map data, without using script?
01:16:34 [heycam]
CL: one provider can provide a script library to do that, btu it makes it difficult to use other providers' data
01:16:47 [heycam]
... the declarative information lets you easily merge it from other providers
01:17:20 [heycam]
AD: the primary benefit of the tiling module is that as you pan out, the resources are already released
01:17:37 [heycam]
... 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
01:17:50 [heycam]
RO: there are a lot of use cases like that, e.g. massive tables of data, an Excel spreadsheet
01:18:12 [heycam]
... those sorts of use cases need to be solved, but SVG shouldn't solve that general problem
01:18:29 [heycam]
... there are a bunch of features that mapping featuers have, even aside from the tiling and LoD stuff
01:22:37 [heycam]
JF: the charter mentions CSS WG
01:22:42 [heycam]
DS: that's a copy/paste error
01:23:15 [heycam]
JF: that makes more sense
01:23:29 [heycam]
... I'd like to discuss one thing
01:23:45 [heycam]
... SVG Map specification, the original one from Takagi-san, was a kind of profile of SVG
01:23:50 [heycam]
... that includes various extensions used for mapping
01:24:05 [heycam]
... after reviewing the specification in SVG IG, and in this group, we decided to modify the specification to split into two parts
01:24:14 [heycam]
... the first part is the Tiling & Layering
01:24:22 [heycam]
... and we think that it's the most important part of the specification
01:24:30 [heycam]
... and we should create a new module to provide such feature
01:24:43 [heycam]
... other features, such as Level of Detail, and the support of z-index, are removed from the original specification
01:24:49 [heycam]
... because we think these features are useful for other use cases
01:25:16 [heycam]
... 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?
01:25:43 [heycam]
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
01:25:53 [heycam]
... and you can give feedback to the TF and the WG in general
01:26:11 [heycam]
... but I think it should be focussed on by the mapping TF
01:26:27 [heycam]
JF: do you still think it's a good idea to continue developing the Tiling & Layering specification?
01:26:37 [heycam]
CL: as a separate specification, from the mapping stuff?
01:26:42 [heycam]
JF: or shoudl we create an SVG Mapping profile again?
01:26:47 [heycam]
CL: no I think splitting it out is good
01:26:56 [heycam]
... mapping gets split out, is smaller, and depends on Tiling & Layering
01:27:01 [heycam]
... that would mean it is more likely to be implemented
01:27:12 [heycam]
... it should continue to take requirements from mapping, but also requirements from other areas like medical imaging
01:27:17 [heycam]
... the way you split it makes sense
01:27:28 [heycam]
JF: the current feature set covered by the Tiling & Layering proposal is a good start for discussion?
01:27:29 [heycam]
DS: absolutely
01:27:40 [heycam]
... the other features you talked about you want generalised, we can talk about those in the SVG WG in general
01:28:44 [heycam]
Topic: SVG in EPUB3
01:29:02 [heycam]
JF: I've been involved in the EPUB standardisation, in the last 24 months
01:29:46 [heycam]
... 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
01:30:06 [heycam]
... currently IPDF is working on the new version of EPUB, 3.0
01:30:10 [heycam]
... that's a major revision of EPUB
01:30:15 [heycam]
... it's expected to be released in May
01:30:32 [heycam]
... major new features include support for multimedia functions -- video and audio -- as well as scripting and interactivity
01:30:44 [heycam]
... also supports global language capabilities
01:30:52 [heycam]
... also improved accessibility, enhanced styling and layout features
01:31:05 [heycam]
... there is a public review draft and it was released on Feb 15
01:31:17 [heycam]
... they are currently under review
01:31:32 [jun]
http://idpf.org/epub/30/spec/epub30-overview.html
01:31:41 [heycam]
... here you can get the overview document
01:31:47 [heycam]
... EPUB3 actually consists of various parts
01:31:55 [heycam]
... that's the overview page
01:32:17 [heycam]
... there's also EPUB Publications, EPUB Content, EPUB Media Overlays
01:32:27 [heycam]
... also a list of changes from EPUB2
01:32:30 [shepazu]
s/paste error/paste error, which I've now fixed/
01:32:32 [heycam]
... they're linked to from the overview document
01:32:58 [heycam]
... I will quickly summarise the important points
01:33:05 [heycam]
... one is that EPUB3 is based on HTML5
01:33:12 [heycam]
... EPUB2 used to be based on XHTML 1.0
01:33:22 [heycam]
... they use the XML serialisation of HTML5
01:33:46 [heycam]
... with namespaced SVG content
01:33:57 [heycam]
... for EPUB3, HTML as well as SVG can be the root document
01:34:08 [heycam]
... so you don't need to use SVG from inside HTML
01:34:21 [heycam]
CL: can you put HTML5 inside a <foreignObject> in SVG?
01:34:23 [heycam]
JF: yes
01:34:26 [heycam]
... both are possible
01:34:35 [heycam]
ED: is foreignObject required?
01:34:55 [heycam]
AD: it's required, and I think it's a subset of HTML elements that must be supported in foreignObject
01:35:10 [heycam]
... I think there's a restriction on the size of the foreignObject content
01:35:27 [heycam]
JF: EPUB used to be considered a text oriented format
01:35:46 [heycam]
... but now we can use EPUB3 for more layout oriented document, using SVG, or we can create comics -- graphically oriented documents
01:35:52 [heycam]
... that's good news for us
01:36:06 [heycam]
JF: for styling EPUB3, it supports CSS 2.1
01:36:11 [heycam]
... also supports several CSS3 modules
01:36:34 [heycam]
... the baseline is CSS2.1, but also supports CSS Speech module and css3-fonts, to use embedded fonts, including WOFF fonts
01:36:42 [heycam]
... it also supports css3-text
01:36:46 [heycam]
... and css3-writing-modes
01:37:01 [heycam]
... these two modules are very important to support vertical writing in Japanese lanugage
01:37:15 [heycam]
... we're working closely with fantasai and other CSS WG members to make sure these specifications are ready for use
01:37:30 [heycam]
... probably you know there is a new WD published on css3-writing-modes and css3-text
01:37:35 [heycam]
... which is referenced by the current draft
01:38:35 [heycam]
... EPUB3 also supports CSS MQ, css multicolumn layout, also some extensions specific to EPUB to support ruby
01:38:48 [heycam]
... it defines some EPUB-specific display properties
01:39:06 [heycam]
... EPUB WG decided to define the ruby module as a temporary solution, because W3C does not have a good specification for ruby
01:39:19 [heycam]
CL: html5 has some basic support for ruby, but doesn't have very good support
01:39:28 [heycam]
... did it not meet your needs, and you had to create a new one?
01:39:29 [heycam]
JF: yes
01:39:40 [heycam]
CL: it would be good to transmit that information to the HTML WG, ideally before LC
01:41:08 [heycam]
AD: EPUB doens't use css3 paged media module
01:41:29 [heycam]
... they say different screen sizes will make intelligent decisions
01:41:52 [heycam]
... their recommendation is to use SVG documents for exact page layout
01:43:52 [heycam]
CL: in the Content Documents, it says "restrictions on SVG 1.1"
01:43:55 [heycam]
... the last one is puzzling
01:44:04 [heycam]
... "it should include the width/height attributes on the svg element"
01:44:30 [heycam]
http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions
01:44:31 [ChrisL]
http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-svg-restrictions
01:45:00 [heycam]
... if it's inline, you would use width/height
01:45:29 [heycam]
... 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?
01:45:41 [heycam]
JF: I have no idea. I think it's a good idea to give feedback to the EPUB WG.
01:46:18 [heycam]
AD: judging by their overview document, for targetting different display sizes, use HTML -- but for fixed sizes, you would choose SVG
01:46:38 [heycam]
ACTION: Chris to mail the EPUB WG to ask whether width/height on root <svg> elements should be allowed
01:46:38 [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].
01:46:58 [heycam]
JF: there are several issues in the EPUB WG regarding SVG
01:47:00 [jun]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0129.html
01:47:04 [heycam]
... I sent some of them to the SVG WG mailing list
01:47:22 [heycam]
... the first one is the question about which version of SVG to use in EPUB3
01:47:31 [heycam]
... they currently refer to SVG 1.1 Second Edition
01:47:42 [heycam]
... I'll have to make sure that's the right choice
01:47:44 [heycam]
CL: yes
01:47:52 [heycam]
... second edition fixes hundreds of issues with first edition
01:47:52 [jun]
http://code.google.com/p/epub-revision/issues/detail?id=63
01:48:03 [heycam]
... the last call disposition of comments is almost complete, same for the test suite
01:48:11 [heycam]
... so the next transition will be to Proposed Recommendation
01:48:20 [heycam]
... not clear what will come first SVG 1.1F2, or CSS 2.1
01:49:34 [heycam]
JF: it's good to hear that
01:49:40 [heycam]
... EPUB WG are very serious about their schedule
01:49:51 [heycam]
... they even said they will not publish EPUB3 if it will be delayed
01:50:05 [heycam]
... they will publish some time in May
01:50:39 [jun]
http://code.google.com/p/epub-revision/issues/detail?id=76
01:50:47 [heycam]
... another questions is about the use of RelaxNG schema in the specification
01:51:02 [heycam]
... they currently use the schema published with SVG 1.1 First Edition
01:51:08 [heycam]
... it's not normative
01:51:12 [heycam]
CL: also it wasn't produced by the WG
01:51:17 [heycam]
... we did produce a schema for 1.2T
01:51:24 [heycam]
... we did plan to produce one for 1.1F2 based on that
01:51:33 [heycam]
... that's hard work, we couldn't get someone to do it on contract
01:51:56 [heycam]
... we would love to have a schema that murata-san produced for us, since he knows relaxng very well
01:52:12 [heycam]
... but not starting with the 1.1F2 one, since it's just a DTD conversion
01:52:31 [heycam]
JF: what can we do about this?
01:52:48 [heycam]
CL: I can write to murata-san and ask him about this
01:53:18 [heycam]
JF: is there any plan to prepare a normative RNG schema for 1.1F2?
01:53:21 [heycam]
CL: it was planned
01:53:31 [heycam]
... I'm not sure it would get published at the same time as the spec
01:53:42 [heycam]
... we could produce another specification called RelaxNG schema for SVG 1.1F2
01:53:49 [heycam]
... in general W3C is not putting schemas under technical reports
01:53:55 [heycam]
... it puts them somewhere else
01:54:01 [heycam]
... we normally have a dated schema, as well as a current one
01:54:48 [heycam]
... a simple standards track spec for the schema would be ok to do
01:55:54 [heycam]
JF: we are happy to review his result, to make sure it reflects the changes in second edition?
01:55:55 [heycam]
CL: ye
01:55:58 [heycam]
s/ye/yes/
01:56:08 [heycam]
ACTION: Chris to contact Murata-san about an RNG schema for SVG 1.1 Second Edition
01:56:08 [trackbot]
Created ACTION-2987 - Contact Murata-san about an RNG schema for SVG 1.1 Second Edition [on Chris Lilley - due 2011-03-09].
01:57:29 [heycam]
JF: as you may notice, SVG animation is not allowed in EPUB
01:57:36 [heycam]
... and some of you might be happy or unhappy with this
01:57:44 [heycam]
CL: I felt it was OK, and I understood why
01:57:59 [heycam]
... e.g. there are ebook readers that have unpowered displays
01:58:04 [heycam]
... but I see scripting can also be supported
01:58:18 [heycam]
AD: peter sorotokin said that it was because it was just thought to be not important
01:58:32 [heycam]
BB: if you're targetting manga, you can get manga on keitai that are animated
01:58:51 [heycam]
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
01:58:57 [heycam]
DS: so for EPUB4
01:59:00 [heycam]
CL: I can understand it
01:59:03 [heycam]
... that's fine
01:59:13 [heycam]
JF: do we want to suggest to use CSS Animation?
01:59:19 [heycam]
CL: the two are being harmonised, so neither is more stable
01:59:29 [heycam]
... I would suggest to use the harmonised result of that, which can be used from SVG or CSS
01:59:31 [heycam]
... in EPUB4
01:59:49 [heycam]
JF: the next issue is about the CSS properties defined in SVG
02:00:06 [heycam]
... people think we will probably prepare one stylesheet to cover both SVG and HTML content
02:00:18 [heycam]
... in that case, is it OK to use SVG specific CSS properties in ... ?
02:00:22 [heycam]
CL: each specification can add more properties
02:00:27 [heycam]
... CSS is the set of all defined properties
02:00:34 [heycam]
... and they can all go in one style sheet
02:00:57 [heycam]
... you can use CSS3 namespace selectors to select SVG element explicitly
02:01:09 [heycam]
JF: css namespaces is not used in EPUB3
02:02:36 [heycam]
... if you use CSS namespaces, there is no problem to share the single style sheet for both SVG and HTML
02:02:48 [ChrisL]
http://www.w3.org/TR/css3-namespace/
02:02:56 [ChrisL]
CSS Namespaces Module
02:02:56 [ChrisL]
W3C Candidate Recommendation 23 May 2008
02:03:21 [heycam]
... EPUB WG is planning to develope some kind of EPUB check program
02:03:33 [heycam]
... they plan to use W3C CSS validation service within their check program
02:03:49 [heycam]
... they want to see the support of some kind of EPUB3 profile as one of the profiles supported by the css3 validator
02:03:58 [heycam]
DS: if they are willing to do some work on that, I don't think that will be a problem
02:05:35 [heycam]
ACTION: Talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties
02:05:35 [trackbot]
Sorry, couldn't find user - Talk
02:05:43 [heycam]
ACTION: Christ to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties
02:05:43 [trackbot]
Sorry, couldn't find user - Christ
02:05:48 [heycam]
ACTION: Chris to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties
02:05:48 [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].
02:06:14 [heycam]
JF: another issue is about font embedding
02:06:20 [ChrisL]
s/Christ/@SVGesus/
02:06:24 [heycam]
... in EPUB3, the support of WOFF format is mandatory
02:06:31 [heycam]
... you can also support SVG Fonts optionally
02:06:43 [heycam]
CL: I was happy with it until today, when we decided we were going to require SVG Tiny font support
02:06:48 [heycam]
... maybe that changes it?
02:07:22 [heycam]
JF: EPUB3 references SVG 1.1 though
02:07:34 [heycam]
CL: in SVG 1.1, Tiny fonts don't have vertical
02:08:07 [ChrisL]
but 1.1 fonts do
02:08:20 [heycam]
DS: what is the lifecycle of EPUB? when will EPUB4 come out?
02:08:26 [heycam]
JF: some of the WG members have started working on the next version
02:08:32 [heycam]
... some of the features are omitted from the EPUB3 draft
02:08:41 [heycam]
... some of the features might take some time to be finished, so they're moved to the next version
02:08:52 [heycam]
DS: how long between EPUB2 and EPUB3?
02:08:57 [heycam]
JF: over three years now
02:09:09 [heycam]
... some people want to have EPUB 3.1
02:09:19 [heycam]
DS: so anywhere from 1-4 years is likely for another version of EPUB
02:10:28 [heycam]
JF: our feedback to the EPUB WG is we are happy with the mandatory support of WOFF?
02:10:30 [heycam]
CL: yes
02:10:39 [heycam]
JF: and suggest to support the Tiny subset of SVG Fonts
02:10:43 [heycam]
CL: with vertical support
02:10:46 [heycam]
DS: that's our suggestion
02:10:56 [heycam]
JF: should it be mandatory in EPUB?
02:11:20 [heycam]
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
02:11:55 [heycam]
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?
02:12:14 [heycam]
CL: if we had infinite time
02:12:22 [heycam]
AD: it could be reused for SVG2
02:15:29 [ChrisL]
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite
02:15:41 [heycam]
JF: one more issue
02:15:46 [jun]
http://idpf.org/epub/30/spec/epub30-ocf.html#font-obfuscation
02:15:48 [heycam]
... font embedding
02:16:05 [heycam]
... it's about font obfuscation
02:16:31 [heycam]
CL: are you asking is the right thing to do?
02:16:33 [heycam]
JF: yes
02:16:40 [heycam]
... the current version of EPUB has similar features
02:16:44 [heycam]
... in order to allow the embedding of OTF fonts
02:16:55 [heycam]
... now EPUB decided to support WOFF fonts
02:17:04 [heycam]
... so it seems possible to just embed WOFF fonts without using obfuscation
02:17:12 [heycam]
CL: I think obfuscation... it's easy to undo
02:17:17 [heycam]
... so it's a picket fence, it's not protection in any sense
02:17:23 [heycam]
... but you have to actively do something to circumvent it
02:17:33 [heycam]
... I feel that information is better than a half hearted attempt at protection
02:17:44 [heycam]
... with WOFF it has the license right there in the file, which I think is better
02:18:11 [heycam]
... I don't think it's actively harmful to have the obfuscation, and now that you have woff, you shouldn't need it
02:18:19 [heycam]
... but if there is an agreement to have it then maybe there is some value
02:18:42 [heycam]
AD: XPS introduced the same obfuscation in their pacakaging, and it's more to make the foundries be happy to embed fonts
02:18:53 [heycam]
CL: I know that many foundries are happy with WOFF
02:19:21 [heycam]
... 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
02:19:31 [heycam]
s/... I think/AD: I think/
02:19:49 [heycam]
CL: my feedback is not to remove the obfuscation, but to reexamine that it still adds value, now that you have WOFF
02:20:07 [heycam]
JF: one more comment
02:20:09 [jun]
http://bizpal.jp/epub/00010
02:20:36 [heycam]
... that screenshot is using webkit to do vertical text layout
02:20:51 [heycam]
... this uses most of the proposals of css3 vertical text/writing modes, implemented in webkit
02:21:04 [heycam]
... there's a link on that page to the source content of that webpage screenshot
02:21:04 [ChrisL]
http://bizpal.jp/epub/ShowImage?id=32aefbb2-4626-4ec9-b0da-faa78491588f
02:21:24 [heycam]
... I want to encourage mozilla guys to consider supporting vertical writing in order to be used as an EPUB reading system
02:21:30 [heycam]
... to be compatible with japanese vertical writing content
02:21:38 [heycam]
CL: are any mozilla people looking at that?
02:22:11 [heycam]
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
02:22:16 [heycam]
... which quite deeply affect how you actually do it
02:22:29 [heycam]
... and I know John Daggett had some strong opinions on it
02:23:14 [heycam]
AD: a general question: is the group developing any conformance test suite?
02:23:18 [heycam]
JF: yes, they're working on it
02:23:24 [heycam]
AD: will it be publicly available?
02:23:28 [heycam]
JF: I think so, but I'm not sure
02:23:32 [heycam]
... canon is not a member of EPUB WG
02:23:44 [heycam]
... but I'm an invited expert
02:24:37 [heycam]
(break)
03:02:02 [heycam]
Topic: compositing a bit more
03:08:15 [anthony_nz]
http://dev.w3.org/SVG/modules/compositing/master/Overview.html
03:08:38 [heycam]
AG: I've moved the text around a bit, so it follows on a bit better
03:08:42 [heycam]
... extended "object" a bit
03:08:53 [heycam]
... explained what to do to get the outline of the objects
03:09:54 [dholbert]
" A User Agent MUST effect the pixel region as specified by the 'clip-to-self' property. " --> s/effect/affect/ I think
03:11:53 [ed]
"The optional vaues for the new property is under consideration" --> s/vaues/values/ too
03:13:40 [heycam]
DS: if the compositing stuff is useful, is there anything svg specific about it? or should it be in css?
03:13:41 [heycam]
AD: it should be in css
03:14:02 [heycam]
DS: it'd be nicer if people who have svg or css UAs could implement it royalty free
03:14:15 [heycam]
AD: i think the porter duff modes are less useful for css content, but blend modes are very useful
03:14:36 [heycam]
Topic: SVG DOM list object identity
03:15:00 [heycam]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVGXxxList-issues
03:15:29 [heycam]
JW: there are various things that are unspecified in the current SVG spec
03:15:37 [heycam]
... there are a few things that implementations aren't interoperable on
03:15:42 [heycam]
... I have here a proposal for how I think it should work
03:15:53 [heycam]
... which is biased towards how we do it, but we can talk about the pros and cons of it
03:16:14 [heycam]
... one of the topics is the SVGAnimatedLengthList object
03:17:04 [heycam]
... when the SVGAnimatedLengthList object should be thrown away and replaced with a new object, such as a setAttribute call
03:17:12 [heycam]
AD: you want it to be live?
03:17:22 [heycam]
JW: that implies changes you make to it are reflected to the screen
03:17:34 [heycam]
... for the entire lifetime of the document
03:17:55 [heycam]
... to be more specific, the object is never replaced with a different object
03:18:11 [heycam]
... unless, as an optimization, the script would not be able to detect it has changed
03:18:28 [anthony]
anthony has joined #svg
03:18:44 [heycam]
... 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
03:19:31 [heycam]
DH: that behaviour's not part of the spec?
03:19:35 [heycam]
JW: it's ambiguous
03:19:43 [heycam]
... currently we never throw the object away
03:20:03 [heycam]
s/we/we (mozilla)/
03:20:12 [heycam]
... opera seems to throw it away in some circumstances that don't make sense to me
03:20:29 [heycam]
... webkit never throws it away
03:20:36 [heycam]
... IE always keeps the same object as well
03:20:48 [heycam]
... the only exception is opera, which sometimes throw it away
03:21:01 [heycam]
ED: seems like a bug
03:21:05 [heycam]
JW: no objections to speccing it?
03:21:09 [heycam]
ED: where would you spec it?
03:21:24 [heycam]
... 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
03:21:28 [heycam]
JW: but going forward?
03:21:29 [heycam]
ED: that's fine
03:21:50 [heycam]
JW: then there's the identity of the baseVal and animVal objects
03:22:11 [heycam]
... I suggest we never throw away that object if script has references to them
03:22:15 [heycam]
... same idea
03:22:18 [heycam]
... then there's the item themselves
03:22:37 [heycam]
... 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
03:22:42 [heycam]
... objects are just references into the list
03:22:55 [heycam]
... so if any of these 7 things happen, we still return the same object
03:23:54 [heycam]
CM: seems reasonable
03:25:14 [heycam]
ED: we should use these tests and convert them to use the new testing framework
03:27:01 [shepazu]
http://nodelist.org/
03:28:13 [heycam]
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
03:28:32 [heycam]
CM: but consistent with NodeList
03:28:39 [heycam]
JW: it depends how you conceptually see them
03:28:42 [heycam]
... are they like a js array?
03:28:53 [heycam]
... the conclusion of thinking of it like that, is to allow items in more than one list
03:29:25 [heycam]
CM: could thrown an exception
03:29:33 [heycam]
JW: it appeals to me in some way, to thrown an exception
03:29:39 [heycam]
... forces authors to be explicit
03:29:58 [heycam]
CM: i don't like copy
03:30:09 [heycam]
JW: in gecko, if the item doesn't belong to anything, it'll insert it into the list
03:30:15 [heycam]
... if it does belong to another list, it'll insert a copy
03:30:33 [heycam]
... reasoning being if you create one with createSVGLength, you probably want to edit that SVGlength object you just inserted
03:30:58 [heycam]
... the reason we copy is due to considering it to be a list, rather than a dom tree
03:31:30 [heycam]
... and it avoids confusing behaviour
03:36:44 [homata_]
homata_ has joined #svg
03:42:25 [heycam]
[discussions about options]
04:02:53 [homata]
homata has joined #svg
04:04:30 [homata_]
homata_ has joined #svg
04:05:52 [heycam]
(we eventually agree to throw when you try to insert an SVGLength into an SVGLengthList if that SVGLength is currently owned by anything else)
04:06:14 [heycam]
ACTION: jwatt to write spec text about insertItem etc. throwing when the object already has an owner
04:06:14 [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].
04:06:19 [dholbert]
s/by anything else/by anything/
04:06:25 [dholbert]
(including the same list)
04:07:12 [heycam]
JW: last case is mutability
04:07:44 [heycam]
... the way IE and Mozilla implement animVal lists and their items, they're read only
04:07:48 [heycam]
... while they're still in the document
04:07:54 [heycam]
... for opera and webkit, they're mutable
04:08:16 [homata__]
homata__ has joined #svg
04:08:20 [heycam]
... you can't change the list
04:09:26 [heycam]
... 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
04:10:34 [heycam]
ISSUE: animVal list items that are removed from their list should become mutable
04:10:34 [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 .
04:12:56 [homata__]
homata__ has joined #svg
04:13:46 [heycam]
ISSUE: Define how SVGLengths resolve % (and other) values when they are not owned by an element
04:13:46 [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 .
04:15:41 [heycam]
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
04:15:41 [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].
04:15:46 [heycam]
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
04:15:46 [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].
04:16:23 [heycam]
trackbot, end telcon
04:16:23 [trackbot]
Zakim, list attendees
04:16:23 [Zakim]
sorry, trackbot, I don't know what conference this is
04:16:24 [trackbot]
RRSAgent, please draft minutes
04:16:24 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/03/01-svg-minutes.html trackbot
04:16:25 [trackbot]
RRSAgent, bye
04:16:25 [RRSAgent]
I see 12 open action items saved in http://www.w3.org/2011/03/01-svg-actions.rdf :
04:16:25 [RRSAgent]
ACTION: ChrisL to request puiblication of compositing spec [1]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T20-47-54
04:16:25 [RRSAgent]
ACTION: Doug to fix the images in the compositing spec [2]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T20-48-56
04:16:25 [RRSAgent]
ACTION: Anthony to clarify clip-to-self behavior [3]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T21-08-17
04:16:25 [RRSAgent]
ACTION: Anthony to fix advanced gradients spec [4]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T22-14-51
04:16:25 [RRSAgent]
ACTION: Chris to mail the EPUB WG to ask whether width/height on root <svg> elements should be allowed [5]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T01-46-38
04:16:25 [RRSAgent]
ACTION: Chris to contact Murata-san about an RNG schema for SVG 1.1 Second Edition [6]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T01-56-08
04:16:25 [RRSAgent]
ACTION: Talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [7]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T02-05-35
04:16:25 [RRSAgent]
ACTION: Christ to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [8]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T02-05-43
04:16:25 [RRSAgent]
ACTION: Chris to talk to Yves Lafon about adding a new profile to the CSS validator for EPUB3-supported properties [9]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T02-05-48
04:16:25 [RRSAgent]
ACTION: jwatt to write spec text about insertItem etc. throwing when the object already has an owner [10]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T04-06-14
04:16:25 [RRSAgent]
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 [11]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T04-15-41
04:16:25 [RRSAgent]
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 [12]
04:16:25 [RRSAgent]
recorded in http://www.w3.org/2011/03/01-svg-irc#T04-15-46