SVG Working Group Teleconference -- 09 Jun 2009

<trackbot> Sorry, heycam, I don't understand 'trackbot, hello'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<trackbot> See http://www.w3.org/2005/06/tracker/irc for help

<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

http://dev.w3.org/SVG/modules/color/master/color-syntax.txt

<heycam> ACTION-2550: 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

http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG,Summary&alts=j&statuses=rec,cr,wd,ietf

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

http://www.selenic.com/mercurial/wiki/CvsConcepts

<ed> break for lunch

<ed> back from lunch

DS: Like to lookat the polar element, and nurbs

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> 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> 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 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].

http://dev.w3.org/csswg/css3-values/

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

AG: it's similar to the stuff CRF in EXI have done

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> 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 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> http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement

<ed> 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 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="http://www.w3.org/2000/svg"

put that as the first child of your <svg id="svgroot" width=".." ...> result element

<anthony> xmlns:xlink="http://www.w3.org/1999/xlink">

AG: cdata sections will get stripped out

http://www.w3.org/TR/xslt#output

<karl> hi ChrisL

- DRAFT -

SVG Working Group Teleconference

09 Jun 2009

Attendees

Contents