IRC log of svg on 2009-06-09

Timestamps are in UTC.

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