- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 09 Jun 2009 19:33:50 -0400
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes from day 2: http://www.w3.org/2009/06/09-svg-minutes.html or as text below: [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 09 Jun 2009 See also: [2]IRC log [2] http://www.w3.org/2009/06/09-svg-irc Attendees Present Cameron, Erik, Doug, Jonathan, Chris Regrets Chair Erik Scribe Cameron Contents * [3]Topics 1. [4]SVG2 2. [5]making things properties 3. [6]Fonts 4. [7]Print / Color 5. [8]Compositing 6. [9]Transforms 7. [10]WebCGM digression 8. [11]back to transforms 9. [12]SVG 1.1 Second Edition * [13]Summary of Action Items _________________________________________________________ <trackbot> Sorry, heycam, I don't understand 'trackbot, hello'. Please refer to [14]http://www.w3.org/2005/06/tracker/irc for help [14] http://www.w3.org/2005/06/tracker/irc <trackbot> See [15]http://www.w3.org/2005/06/tracker/irc for help [15] http://www.w3.org/2005/06/tracker/irc <trackbot> Date: 09 June 2009 <ChrisL> ScribeNick: ChrisL SVG2 CL: we have a bunch of open issues on svg2 now, things to discuss that wewre deferred ED: Start from a spec CM: Start from scratch, no grandfathering. More concise ... examples are fine, but crisper conformance statements JW: should not need the examples to understand the rest CM: Not as pseudocodey as HTML5 ED: Goal is to pick parts from tiny 1.2 and full 1.1, merged into one spec CM: Also some things that are not the right thing that we could change CL: Is it possible to conform to both svg2 and svg 1.1/1.2T? Need to decide on expectetions for older user agents etc CM: Once svg2 is in the repo it will lead away from fixing up 1.1 ED: merging does not exclude mobile, this is a spec for desktop and mobile. new iphone supports acid 3 as an example ... opera 9.7 on windows mobile also passes CM: Forwards/back compat like Tiny, not a complete break CL: So not a new mime type for example CM: Userr base is more adapatble <ed> s/also passes/gets a 100/100 score/ cl: we bneed to not piss off existing adopters like inkscape, kde, xslfo+svg users <ed> s/scored 100 out of 100/gets a 100\/100 score/ CL: perhaps we could list our hated or unuseful features JW: eRR needs better defined ED: vertical text needs better defined JW: Lets have a wiki page for this CL: two secions, one hitlist for dropping and one underdocumented list [16]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt [16] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt <heycam> ACTION-2550: [17]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt [17] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt <trackbot> Sorry... adding notes to ACTION-2550 failed, please let sysreq know about it [18]http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG,Summa ry&alts=j&statuses=rec,cr,wd,ietf [18] http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG CL: so i think that gradients which link to other gradients has turned out to be a misfeature ... Markers are an issue, in a new language i would not have markers, instead i would have a separate polymarker element ... painted bounding box JW: getting pbb is very expensive ed: yes, it can be. requires off screen painting in many cases (some yes it is, no it isn't ratholing) my it seems to be almost lunchtime [19]http://www.selenic.com/mercurial/wiki/CvsConcepts [19] http://www.selenic.com/mercurial/wiki/CvsConcepts <ed> break for lunch <ed> back from lunch DS: Like to lookat the polar element, and nurbs [20]http://en.wikipedia.org/wiki/Nurbs [20] http://en.wikipedia.org/wiki/Nurbs making things properties ED: CSS wg seemed to think some of our attrs were suitable as properties, not all of them CL: So you want to make all attrs properties, doug? DS: Yes prtetty much CL, JW: Why? <ed> ACTION-2569? <trackbot> ACTION-2569 -- Erik Dahlström to draft a proposal to have width and height properties -- due 2009-05-27 -- OPEN <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/actions/2569 [21] http://www.w3.org/Graphics/SVG/WG/track/actions/2569 DS: Want to use classes to affect other things than style. d== no, href, id, no.... JW: Prefer to add on a case by case basis ED: yes DS: More a thought exercise CM: Could use stuff from css3 values and units, so calc() CL: Would rather have a calculation facility that would work on attrs and properties CM: My thinking was that if its easy to turn attr to prop to get that functionality then do that ... if we can ger a syntax that works on non-property attrs that is good ED: So see which of ourt attrs have an existing css property, width and height obvious ones CM; If they have the same meaning <heycam> [22]http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html [22] http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html s/outs/our/ ED: Is there a global list of all css properties from all css3 drafts? CL: Not as far as I know document.properties.iterate() (discussion on the difficulty of aggregating specs from multiple WGs) ED: transform is going into css, so there is anothetr one. need to define for 2dtx CM: Likely that animatable attes should be properties (as a first cut) ... transform, width, height ED: x1 y1 cx cy etc do not have a direct mapping, but could be more useful DS: rx ry has applicability, rounded corners CL: thats border-radius JW: Properties that inherit into stuff need to have consistent meanings from html and css. not so critical for non-inherited properties ... Concerned over making everything a property CL (amusing tale of xml:id becoming inherited in C12n) ED: Could get benefts by yusing transform together with width and height CM: Not with rounded corners ... rx has different meaning on rect and ellipse DS: Not terribly different ... Yesterday I mentioned wanting rx, ry and stroke on image, as a poor mans clippath ... Is there an optimisation hit for that ... not sure its worth it. But typically can see the thing you are clipping CM: Can use 'use' in clippath ... pointing to a graphical shape (brief discussion about ITU liaison as we remember they meet soon) ED: Some things that udom is good for and full dome does not cover, like pulling out a path from a glyph element ... missing from 1.1, should be added ... typed access is better for presentation properties, better than dom2 style CM: onclick, not a property (digression on JSRs) CM: things that have lengths DS: Things that don't have complex types cm: polyline - list of numbers, nt lengths ds: often wanted a percentage on a path. CM: Or H 2em ED: How does css transform integrate into svg, and what about gradient transform? ... why is it even called gradient-transform and not just transform ... and pattern-trandform CL: and svg:transform CM: Points is ok as a property value, but not things more complex than lists of simple types (digression on consistent list syntax in SVG2) ED: Mozilla has transforms in css. does it aply to svg, currently JW: No it does not, yet ... need to say the property is mapped , or that it takes precedence ... practicval difference if its made to inherit ED: Not difficult to make it inherit JW: what if therre is an animateTransform ED: Works on the eventual transform, after cascading <ed> CL: (explains CSS and XML animation) <heycam> CL: doing <animate attributeType="XML" attributeName="stroke"> animates the property, it's not possible to animate the presentation attribute separately ed: JW could you look into how svg transforms and css transforms interact on svg content? JW: sure <scribe> ACTION: jwatt to look into how svg transforms and css transforms interact on svg content? [recorded in [23]http://www.w3.org/2009/06/09-svg-minutes.html#action01] <trackbot> Created ACTION-2603 - Look into how svg transforms and css transforms interact on svg content? [on Jonathan Watt - due 2009-06-16]. [24]http://dev.w3.org/csswg/css3-values/ [24] http://dev.w3.org/csswg/css3-values/ [25]http://dev.w3.org/csswg/css3-values/#the-calc-function [25] http://dev.w3.org/csswg/css3-values/#the-calc-function so calc only does constant expressions on lengths which must have a unit <atomic-length> := <number><length-unit> Issue: At a later date new operators such as min/max, conditionals, new constants, division by length units etc. may be added. <trackbot> Created ISSUE-2278 - At a later date new operators such as min/max, conditionals, new constants, division by length units etc. may be added. ; please complete additional details at [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit . [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit <heycam> CM: it'd be a bit annoying to have to say <rect width="10px"> instead of <rect width="10"> <heycam> CM: oh no, it's the scientific notation that is restricted <heycam> CM: so you couldn't say <rect width="1.23e5"> <heycam> CM: and scientific notation is primarily useful for geometric attributes like width="" on <rect> <ed> [27]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-s cientificnotation.svg [27] http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-scientificnotation.svg <ed> Opera, Firefox and Safari all behave slightly different on that testcase (we agree to try again to get sci.not accepted in css) CM: units optional in presentation attrs, but required in stylesheets <scribe> ACTION: jwatt rock the roc re sci.not [recorded in [28]http://www.w3.org/2009/06/09-svg-minutes.html#action02] <trackbot> Created ACTION-2604 - Rock the roc re sci.not [on Jonathan Watt - due 2009-06-16]. Fonts <ed> scribeNick: ed CL: we have a fonts module, but it's not checked in ... john daggett has done some of the work ... subsetting to the parts that are implemented ... extended fontmatching stuff dropped ... things that are missing: standalone spec for svgfonts with different conformance levels, for xsl ... though they might also want opentype fonts ... extensions of fonts, vertical text ... other things missing: xml syntax ... svgs xml syntax, other spec could cameleon it into another spec ... commenting on css3 fonts ... jdaggett is writing tests ... I'm converting them to svg syntax ... want to put them into the svg testsuite ... he's only testing HTML implementation CM: saw the mail you sent out about existing implementatioins ... among which are several svg impls CL: i feel we need more font tests ... good to see opera shipping with support for svgfonts and truetype fonts CM: what about hte module? CL: if it's useful to make a module then I can do the work CM: useful if we need to define something for xsl ... wopuld the module have @font-face equivalent, would it require svgfonts? CL: don't think so, they're more interested in opentype fonts ... downloadable fonts DS: they're doing print stuff right ... why wouldn't they want svgfonts? ... having a supplementatry spec to svgtiny12 would be good for JIS ... for vertical text CM/CL: good point CM: just wondering if it was worth having a module DS: for vertical text yes ... but does it belong in a font module? CL: font support for vertical text belongs in a font module (discussion of vertical text missing in tiny12) CL: easy to make fonts standalone with added support for vertical ... difficult if it ties into the rest of svg, gradients etc DS: (draws on whiteboard) ... want to annotate text ... and selectable CL: you could do one glyph with complex subshapes ... inkscape added some functionality for drawing svgfonts ... do you want an ALT tag? DS: just some way of saying something is text, and this is what it represents ... title with a role=text? ... talked to designers, making svg posters made more difficult because of lacking support CL: who in moz is working on that btw? JW: jdaggett I think CL: happy to help if it's needed JW: he started asking about svgfonts (discussion about blocked bugs) CL: making a module that does tiny fonts + vertical font ... we're not sure about the xml serialization of @font-face (for possible reuse by xsl) CM: if JIS is interested question is, what use is it without support for vertical text? CL: yeah, it's more useful when combined <scribe> ACTION: CL to commit the SVG Fonts module, removing the parts already covered by CSS3 Fonts [recorded in [29]http://www.w3.org/2009/06/09-svg-minutes.html#action03] <trackbot> Created ACTION-2605 - Commit the SVG Fonts module, removing the parts already covered by CSS3 Fonts [on Chris Lilley - due 2009-06-16]. break for a moment, waiting for anthony to join for discussion on print/transform/color/compositing modules Print / Color AG: CL you split out color right? CL: yes <heycam> Scribe: Cameron <heycam> ScribeNick: heycam CL: i was at csswg last week and they want to add cmyk support ... i objected on the grounds that they weren't clear on whether they wanted icc cmyk or device color ... implementors are demanding it ... hakon doesn't really understand the difference ... response he got back from implementors is that they want both ... so if you look at the current spec it still has the old stuff about device color ... it says device color is a name followed by a list of numbers ... and the name takes you to a device-color element, which olds an href that points out to who knows what ... and the example uses a numberOfComponents attribute that's not used anywhere, and extension namespaces ... the info about what the colours actually are are in a comment block ... for the common case where you want to say this is device cmyk, how do you do that? ... what uri should i use/mint to represent device cmyk? there isn't an easy way to do that. ... so i started changing the device-color element to make that work ... but the css folks just want a simple property value for that, not indirecting through an xml block <ChrisL> [30]http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html [30] http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html CL: looking at this DoC, all the comments on print ... so you can take a copy of this to make the DoC for the Page module, changing some bits ... there's a lot of green there, except for one purple item "we need to change this" ... i've got proposed text in there to accede to the commentor ... "device color would be better using pseudo profiles ...", and i said we disagree ... but i propose we change that to green/agree, since at the end of the day what you want is device cmyk (very important), device rgb perhaps, device grey, and device multi channel which is just as vague as the current spec ... hexachrome, you could probably do that with an icc profile ... and photo rgb printers like the epsons: cyan, light cyan, magenta light magenta.... 7 colour printers ... but that's no big deal they take sRGB input ... so i've change the device-color token to be one of device-grey, device-cmyk, ... ... device-grey takes one colour ... device-rgb takes three colours ... device-cmyk takes four colours ... unlike the current spec, it tells you what those colour parameters mean ... device-multichannel thing takes how many every colours it takes, and you don't know what they mean ... but that's by far the least useful case anyway AG: would you have a list of numbers that you don't know the length of? CL: yes ... that's the weak part of the proposal ... jeremias from fop wanted these ... so we're giving them exactly that ... csswg wanted something quite similar to this ... so the vendors who want this functionality get both of the things what they want ... and we keep inkscape/scribus happy, who also wanted device cmyk ... so i propose that we adopt this, then i add it, which is easy ... and i'll also add the syntax appendix part <ChrisL> [31]http://dev.w3.org/SVG/modules/color/master/SVGColor.html [31] http://dev.w3.org/SVG/modules/color/master/SVGColor.html AG: did we want to lift any content from my 2007 paper? CL: yes but that would mostly go in the primer ... another thing i've done is i've changed all the defs of the rendering intents ... so it uses HP's wording ... (from the DoC) ... at LGM they were happy about splitting the spec apart DS: people still do want a pagination model, though CL: they may have misunderstood split to mean throw out DS: right ... is canon still interested in pagination? AG: not at the moment ... they're more focussed on the UI stuff at the moment still ... can i get this master version of the spec reviewed by my guys yet? CL: i'd like to publish this, i need to do some responses to the commentors ... so 2 weeks response time for that ... it's public anyway, so you can point them to dev.w3.org AG: many more changes in the next 2 weeks? CL: not apart from folding in that syntax change ... i'm likely to beef up the primer ... add the stuff from your paper AG: we might take the language spec and review it then CL: sure ... i don't think is just ready for another LC yet ... but fairly shortly after this it should ... i do want to move it forward to CR, since there are implementors waiting for it ... one of the other things i've put in is a clear conformance requirement that UAs colour match embedded images ... firstly, the old spec assumed that but didn't mention it really ... it only told you how to override the colour profile with a different one, which is of less interest ... the reason that's important is that firefox and safari both do colour management of images now ... so they would conform to that part, and we can raise bugs if they colour manage images in html and not in svg, and they can reuse code and just hook it up AG: can we still add bits and pieces to the language spec? CL: yes, i'm not asking for a second LC yet, but it's getting close ... so i'll bring that to a telcon, but in a couple of weeks AG: i think it would be good to have something like "preserve black" in there, for text ... so if you have text that's black, and set a preserve black on it, so that it uses the black ink at the cmyk end CL: if you look at the rendering intents, i've change the language. one of the changes is that primarily you should be using relative-colorimetric ... and using that with black point compensation, so if the target device black is not 0, but some measured value of black, you'll map your blacks to that AG: yes but if you wanted to use a different rendering intent, or the one on the profile isn't there since not all profiles support it, then you might run in to problems ... i would like to see preserve black in there ... it's also useful for images CL: so that'd be a second attribute on the <color-profile> element? AG: yeah probably ... although i'll check with the guys here CL: i can add it in to the spec so it sounds reasonable AG: should i propose some wording? CL: yes please <scribe> ACTION: anthony to propose wording for "preserve black" attribute for color profiles [recorded in [32]http://www.w3.org/2009/06/09-svg-minutes.html#action04] <trackbot> Created ACTION-2606 - Propose wording for "preserve black" attribute for color profiles [on Anthony Grasso - due 2009-06-16]. CL: i'm going to start on test cases, tho it's a bit difficult without an implementation AG: does opera support colour management? ED: no CL: firefox 3.5 does, 3.1 did not ... unless you switched on specific prefs ... only on embedded images AG: we'll have to think up of some crafty colour values for the tests CL: for input i found documentation for the macbeth colour checker with measured colour values ... got those values converted to cielab ... from that i can produce srgb values etc., so i've done that here AG: are we going to allow... i know we have solid colour, viewport fill... what other things use colour? feFlood? CL: yes ... flood-color ... it's missing viewport-fill though ... there is an outstanding issue that many profiles don't have all four rendering intents specified, so what do you do if you ask for a rendering intent that's not supplied? AG: i think this was mentioned in the first round of comments from guys here ... they said something on the lines of using fallback, or ignoring it CL: if you allow it to use any rendering intent, you need it to definitely work if it has those rendering intents ... if it only has a single rendering intent, then allow it to use that AG: be good to say in the spec if the rendering intent is not in the profile, then just do colour conversion as normal ... there are also some minor editorial notes that unintentionally limit things, i'll send those in in the next week or so ... the sentence that begins "if icc based named colours are provided" ... in "icc named colour", in the first red box CL: it says it must use it in preference to the fallback AG: we should remove the "use profile connections other than ciexyz or ..." CL: why? ... are there profiles that use other connection spaces? AG: those are two common ones that i know of, don't know, but they could ... it's just limiting CL: i wanted to say that if you get a profile connection space that you don't know about, then you don't use it ... so you use fallback AG: ok i like your wording better <ChrisL> or uses an unsupported profile connection space <scribe> ACTION: Chris to follow up to all commentors on the colour module that haven't been responded to [recorded in [33]http://www.w3.org/2009/06/09-svg-minutes.html#action05] <trackbot> Created ACTION-2607 - Follow up to all commentors on the colour module that haven't been responded to [on Chris Lilley - due 2009-06-16]. <scribe> ACTION: Chris to fold in the edits to the colour module that were discussed at this meeting [recorded in [34]http://www.w3.org/2009/06/09-svg-minutes.html#action06] <trackbot> Created ACTION-2608 - Fold in the edits to the colour module that were discussed at this meeting [on Chris Lilley - due 2009-06-16]. Compositing AG: haven't done much on that, just letting it sit ... still have to fold in cameron's and erik's comments in ... we haven't worked out any common wording for enable-background ED: we did publish a first draft of compositing right? AG: yes DS: there are a few things that would be good to get done by svg open, that you are working on ... compositing e.g., what needs to be done for that? AG: just folding in erik's and cameron's comments Transforms DS: did you respond back to dino about the openvg stuff? AG: openvg is a bit higher level than opengl ... haven't responded back to him about that ... i did ping him and ask him if we can sit down and work out some common ground for the specs, but he seems to be a bit busy at the moment ... he'll get in touch with me some time soon ... i did some reading up on perspective transformations in 3d and looked a number of different ways of doing it ... from what i can tell, and other guys here tell, the way that canon's proposed matches what's currently known and done out there ... we don't understand the use case & reqs that css have ... e.g. for stringing along multiple perspective transformations in the one transform property ... so that's the first thing i need to talk to dino about ... i've played around with webkit for a bit, since they implement the transform stuff ... the results it produces when you apply a perspective transform seem a bit odd ... it's as if it doesn't implement it at all ... so not sure what's going on there CM: it might just be the iphone build of safari AG: i did some testing between the css proposal and ours ... with both you can get the same effects ... but i would like to understand why they want the chainable perspective transformations ... a lot of the other things are similar, and we could use the same syntax/spec for DS: might be useful to still write up why the matrices are the way they are, and the openvg reasons AG: using openvg, you need to render all your graphics to a buffer, flatten it, then apply a 3x3 perspective transform ... the maths is in the spec ... what sort of write up are you looking for? DS: a rationale about why it doesn't hinder the spec to do it this way AG: compared to what css proposes, it doesn't really change anything DS: but we need to justify it AG: another thing we'll need in the transforms spec is, and i'd like the group's opinion on, is an xml syntax for transforms, like we've discussed with paths <anthony> <svg> AG: it's similar to the stuff CRF in EXI have done <anthony> <defs> <anthony> <transform id="rotateX_rotateY"> <anthony> <rotateX angle="45" /> <anthony> <rotateY angle="45" /> <anthony> </transform> <anthony> </defs> <anthony> <rect ... transform="#rotateX_rotateY" /> <anthony> <circle ... transform="#rotateX_rotateY" /> <anthony> <svg> AG: one of the advantages i can see is that you don't need to supply a group around objects to apply a transform, have them referenceable DS: i can see this useful for grouping logically and according to appearance ED: if you have the css transform, it's quite easy to reuse transforms with that DS: so yes i see a use case for it. if it's handled by making transform a property, ... ... probably it's better if we duplicate that functionality [with the xml syntax] AG: with css can you animate a component of the transform? say, the x component? ED: i don't know exactly if it's easy to do that. you'd have to split the transfrom property into several parts. AG: that was one of the other ideas i was thinking of. with the above example, you can animate individual components of a transform. CM: that's the same reasoning for separating out the path commands DS: true ... it reminds me of some things dino wanted to do with scaleX, scaleY, breaking them out into separate commands ... if they are going to be css properties, aren't the going to be svg properties as well? ED: [nods] <ed> [35]http://dev.w3.org/csswg/css3-3d-transforms/#animation [35] http://dev.w3.org/csswg/css3-3d-transforms/#animation CL: if the properties are mapped, you get that for free CM: i think the css proposal doesn't have separate properties for scaleX, scaleY, just separate commands in the one property ED: with css, you can animate individual items CM: and we have weirdo transform animations DS: but as separate attributes, then you don't have the ordering any more ... so it wouldn't work ED: so it doesn't sound like the broken-up xml syntax is what we want CM: will we adopt the css transform animation, or stick with what we have? ED: the decomposition? CM: yes DS: it'd break backwards compat ED: other things break tho, such as center point rotation DS: we should work with css to make sure we all have what we want WebCGM digression CL: their transforms now have a center point for rotations <scribe> ACTION: Chris to mail comments about WebCGM [recorded in [36]http://www.w3.org/2009/06/09-svg-minutes.html#action07] <trackbot> Created ACTION-2609 - Mail comments about WebCGM [on Chris Lilley - due 2009-06-16]. back to transforms AG: so how do we want to handle animations ... the same as tiny? <ed> [37]http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformEl ement [37] http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement <ed> [38]http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances [38] http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances CM: we just do single component animations ED: makes less sense to interpolate individual components in a 3d matrix AG: yeah i guess so ... wondering if there's a use case for it though ... interpolating the whole matrix is definitely useful, individual ones not sure ... e.g. you might translate something then only animate a rotation CM: we could add an <animateTransform type="list"> ED: we could keep the current behaviour, then add this to align with css CM: i like that, maybe it could even be the default if no type="" is specified ... though decomposing the matrix and doing linear interpolation on the components won't give you the same result as linearly interpolating a rotate() parameter ED: so would this go in the 3d transforms spec? AG: i think it belongs in animations chapter of svg 2 ED: yeah <scribe> ACTION: Anthony to raise an issue on SVG 2 about animateTransform with matrix-decomposed interpolation like css [recorded in [39]http://www.w3.org/2009/06/09-svg-minutes.html#action08] <trackbot> Created ACTION-2610 - Raise an issue on SVG 2 about animateTransform with matrix-decomposed interpolation like css [on Anthony Grasso - due 2009-06-16]. AG: other than that, nothing else to discuss on transforms ED: nothing to say on print? AG: no SVG 1.1 Second Edition AG: i'm writing up the script at the moment to run through the xslt to transform the tests ... that should be done tonight CL: make sure you copy across any attributes on the root <svg> element, since some tests put some there AG: ok i'll change the xslt to do that <xsl:copy-of select='@*[local-name() != "id" and local-name() != "width" and local-name() != "height" and local-name() != "viewBox"/> <anthony> <svg id="svg-root" width="100%" height="100%" <anthony> viewBox="0 0 480 360" xmlns="[40]http://www.w3.org/2000/svg" [40] http://www.w3.org/2000/svg put that as the first child of your <svg id="svgroot" width=".." ...> result element <anthony> xmlns:xlink="[41]http://www.w3.org/1999/xlink"> [41] http://www.w3.org/1999/xlink AG: cdata sections will get stripped out [42]http://www.w3.org/TR/xslt#output [42] http://www.w3.org/TR/xslt#output <karl> hi ChrisL Summary of Action Items [NEW] ACTION: anthony to propose wording for "preserve black" attribute for color profiles [recorded in [43]http://www.w3.org/2009/06/09-svg-minutes.html#action04] [NEW] ACTION: Anthony to raise an issue on SVG 2 about animateTransform with matrix-decomposed interpolation like css [recorded in [44]http://www.w3.org/2009/06/09-svg-minutes.html#action08] [NEW] ACTION: Chris to fold in the edits to the colour module that were discussed at this meeting [recorded in [45]http://www.w3.org/2009/06/09-svg-minutes.html#action06] [NEW] ACTION: Chris to follow up to all commentors on the colour module that haven't been responded to [recorded in [46]http://www.w3.org/2009/06/09-svg-minutes.html#action05] [NEW] ACTION: Chris to mail comments about WebCGM [recorded in [47]http://www.w3.org/2009/06/09-svg-minutes.html#action07] [NEW] ACTION: CL to commit the SVG Fonts module, removing the parts already covered by CSS3 Fonts [recorded in [48]http://www.w3.org/2009/06/09-svg-minutes.html#action03] [NEW] ACTION: jwatt rock the roc re sci.not [recorded in [49]http://www.w3.org/2009/06/09-svg-minutes.html#action02] [NEW] ACTION: jwatt to look into how svg transforms and css transforms interact on svg content? [recorded in [50]http://www.w3.org/2009/06/09-svg-minutes.html#action01] [End of minutes] _________________________________________________________ Minutes formatted by David Booth's [51]scribe.perl version 1.135 ([52]CVS log) $Date: 2009/06/09 23:29:25 $ _________________________________________________________ [51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [52] http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at [53]http://dev.w3.org/cvsweb/~checkout~/2002 /scribe/ [53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad s/// command: s/also passes/gets a 100/100 score/ WARNING: Bad s/// command: s/also passes/gets a 100\/100 score/ Succeeded: s/also passes/scored 100 out of 100/ FAILED: s/outs/our/ Succeeded: s/cs/cx/ Succeeded: s/different/difference/ Succeeded: s/of/me of/ Succeeded: s/note/not/ WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> . .. Found ScribeNick: ChrisL Found ScribeNick: ed Found Scribe: Cameron Found ScribeNick: heycam ScribeNicks: ChrisL, ed, heycam Present: Cameron Erik Doug Jonathan Chris Found Date: 09 Jun 2009 Guessing minutes URL: [54]http://www.w3.org/2009/06/09-svg-minutes.html People with action items: anthony chris cl jwatt [54] http://www.w3.org/2009/06/09-svg-minutes.html End of [55]scribe.perl diagnostic output] [55] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 9 June 2009 23:39:25 UTC