See also: IRC log
<trackbot> Date: 01 March 2011
<dholbert> SCRIBENICK: dholbert
AG: That has the latest
... 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?
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
... 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
... 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
... 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
... 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
... 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
... 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)
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
... 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
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?
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
... [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
... 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.
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
... 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
... 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
JF: which are part of unicdode
... 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?
... 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?
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?
... 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 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
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
... 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
... 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?
... 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.
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
... 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?
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?
... 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
... 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?
... but ths SVG JIS committee to work on that standard will be finished in March
DS: maybe version 2 could have some changes?
... 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
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
... then they decided they wanted a first class citizen element
CL: is this how it's specified in the JIS standard?
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,
... I assume that JIS also has such a process?
CL: we could put in feedback that
... 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
... 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
... 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
... 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?
... 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
JF: here you can get the overview
... 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
... 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?
... 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
... 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?
CL: it would be good to transmit that information to the HTML WG, ideally before LC
AD: EPUB doens't use css3 paged
... 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"
scribe: if it's inline, you would
... 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
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
... second edition fixes hundreds of issues with first edition
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
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
... 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?
<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
... 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
... 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
... if you use CSS namespaces, there is no problem to share the single style sheet for both SVG and HTML
<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
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
... 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?
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
JF: one more issue
JF: font embedding
... it's about font obfuscation
CL: are you asking is the right thing to do?
... 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
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
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
... canon is not a member of EPUB WG
... but I'm an invited expert
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
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
... 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
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
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]