06:30:17 <RRSAgent> RRSAgent has joined #svg
06:30:17 <RRSAgent> logging to http://www.w3.org/2009/04/08-svg-irc
06:30:19 <trackbot> RRSAgent, make logs public
06:30:19 <Zakim> Zakim has joined #svg
06:30:21 <trackbot> Zakim, this will be GA_SVGWG
06:30:21 <Zakim> ok, trackbot, I see GA_SVGWG()2:30AM already started
06:30:22 <trackbot> Meeting: SVG Working Group Teleconference
06:30:22 <trackbot> Date: 08 April 2009
06:31:11 <Zakim> +??P1
06:31:29 <anthony> Zakim, ??P1 is me
06:31:29 <Zakim> +anthony; got it
06:32:20 <Zakim> +[IPcaller.a]
06:32:24 <heycam> Zakim, [IPCaller.a] is me
06:32:24 <Zakim> +heycam; got it
06:32:41 <jwatt> Zakim, ??P0 is me
06:32:41 <Zakim> I already had ??P0 as [IPcaller], jwatt
06:32:58 <Zakim> +Doug_Schepers
06:33:12 <Zakim> +??P4
06:33:17 <ChrisL> ChrisL has joined #svg
06:33:23 <ed> Zakim, ??p4 is me
06:33:23 <Zakim> +ed; got it
06:34:23 <Zakim> +ChrisL
06:34:52 <heycam> Scribe: Cameron
06:34:54 <heycam> ScribeNick: heycam
06:34:54 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0016.html
06:34:57 <heycam> Chair: Erik
06:35:10 <heycam> Topic: SVG Integration module
06:35:32 <heycam> DS: not much to show yet, thought i'd get something going
06:35:49 <shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
06:36:39 <heycam> DS: i'm going to start by integrating that embedding document i once wrote
06:36:47 <heycam> ED: sounds good
06:36:52 <shepazu> http://www.schepers.cc/svg/blendups/embedding.html
06:37:17 <heycam> DS: also how to extend svg, starting with what we had in 1.2T
06:37:46 <heycam> ... i'll put in whatever hooks cameron needs for doing the tables of attributes and elements
06:37:57 <heycam> CL: did how we do attributes change recently?
06:38:15 <heycam> CM: still experimenting, once the build scripts are finalised i'll mail the list with details
06:38:27 <shepazu> http://www.w3.org/TR/SVGTiny12/conform.html#ConformingSVGEncoding
06:38:57 <heycam> [doug reads out D.7]
06:39:53 <heycam> CL: nice that that wording is in there
06:40:03 <heycam> DS: does the current svg in html proposal violate that?
06:40:13 <heycam> CL: the intention would be not to violate that, not sure about the current proposal
06:40:18 <heycam> DS: i don't think it does violated it
06:41:06 <heycam> s/violated/violate/
06:43:04 <heycam> DS: as to what hooks to put into the spec to generate the tables of attributes etc., i'll leave it to cameron to work out what's best
06:43:24 <heycam> ... a question about svg in an <img> element
06:44:10 <heycam> ... what if you have svg referenced from html <img>
06:44:19 <heycam> ... <object> has .contentDocument
06:44:21 <ChrisL> script in svg wich is in an image, or script somewhere else getting at svg in an image through script?
06:44:23 <heycam> ... does <img>?
06:44:30 <heycam> ... i'm kind of thinking that we might say no
06:44:37 <heycam> ED: i don't think that would work, at least in opera 10
06:44:47 <heycam> DS: should it?
06:44:59 <heycam> ED: we made a decision not to allow it.  it's just whether you put the interface on that <img> element.  but we chose not to.
06:45:12 <heycam> ... since it doesn't allow scripting inside the referenced document, that's why we chose to leave out the interface
06:45:19 <heycam> CL: but why prevent accessing the document from outside?
06:45:37 <heycam> DS: i think from a security and efficient viewpoint, it might be better not to get at the contents at all
06:46:35 <heycam> ED: my question is, what would happen if you inserted a <script> inside the referenced document?
06:46:47 <heycam> CL: i'm talking about getting to the document at all. whether it's readonly or read-write is a separate question.
06:47:14 <heycam> ... maybe if it comes from a different host you wouldn't be allowed to, but that's just a standard  cross site restriction, nothing to do with it being an <img>
06:47:23 <heycam> DS: if you reference using <object>, <embed>, etc., you already have that capability
06:47:35 <heycam> ... we're talking about one particular embedding scenario that walls it off more
06:48:52 <heycam> CM: perhaps you specifically want to disallow access from the containing html (and to disallow script running inside the svg), hence you'd use <img>
06:49:15 <heycam> DS: the canvas api operates on <canvas> and not <img>, right?
06:49:26 <heycam> ED: yes
06:49:50 <heycam> DS: so you wouldn't be able to modify the image referenced by <img> but not an svg referenced by that element (i.e., there wouldn't be that inconsistency)
06:50:25 <heycam> ... so with <img> you can't access the DOM from the outside
06:50:40 <heycam> CL: if you can't access the DOM from inside or the outside, do you need to build a DOM at all?
06:51:00 <heycam> DS: text
06:51:15 <heycam> CL: might be an accessibility concern if an AT can't access the text as a DOM 
06:51:56 <heycam> CM: perhaps the AT uses privileged methods to get at the DOM, not just standard script in the web page
06:52:04 <heycam> DS: in the html wg we're discussing accessibility of canvas
06:52:36 <heycam> ... for the purposes of svg in <img>, there might be an api (mini dom?) hanging off the <img> that exposes the text information and nothing else
06:52:53 <heycam> ED: i would prefer in that case to have specialised access for ATs
06:53:10 <heycam> ... i started to look at this; we still have the DOM for SVGs referenced by <img>, so in our source code we can access it
06:53:17 <heycam> ... but you're just prevented from accessing it in script
06:53:28 <heycam> ... i don't think it'd be a problem to expose that information to ATs
06:53:40 <heycam> ... i'd have to check how we integrate with ATs, though, but i don't think it'd be a problem
06:53:49 <heycam> ... i agree that it'd be useful for such tools to be able to access that information inside
06:58:34 <heycam> [discussions about getting AT vendors involved in helping with SVG accessibility speccing]
06:59:29 <heycam> ACTION: Doug to contact AT vendors about SVG accessibility
06:59:30 <trackbot> Created ACTION-2515 - Contact AT vendors about SVG accessibility [on Doug Schepers - due 2009-04-15].
07:00:29 <heycam> DS: i wonder if much of the challenge for them is in drilling in to embedded DOMs (e.g., via <object>)
07:04:03 <heycam> [discussions of appropriate title/desc]
07:04:18 <heycam> DS: this'd be for the svg semantics spec (which would deal with aria, too)
07:04:51 <heycam> ED: another thing for the integration spec would be css fonts and web fonts, whether or not scripts should run in referenced svg fonts
07:05:21 <heycam> CL: if an svg has an @font-face, which points back to the same document; if that document has script, should it run?
07:05:26 <heycam> ... how about if they're in different documents?
07:05:30 <heycam> ... not sure where the line lies
07:06:19 <heycam> DS: some of these trickier decisions fall out from higher level decisions
07:07:22 <heycam> No telcons next week.
07:08:15 <heycam> Topic: Progress on 1.1 second edition
07:08:28 <heycam> ED: what's the status on the scripts?
07:08:47 <heycam> http://mcc.id.au/temp/struct.html
07:09:26 <heycam> CM: changes since last update are the interfaces at the bottom of that
07:10:22 <heycam> http://dev.w3.org/SVG/profiles/1.1F2/master/svg.idl
07:10:50 <heycam> CM: the idl file is using javadoc-style comments now
07:15:47 <heycam> heycam has left #svg
07:15:57 <heycam> heycam has joined #svg
07:16:46 <heycam> [people are happy with javadoc-style comments in the idl]
07:16:53 <ChrisL> (discussion about svg)
07:16:57 <heycam> CL: what are we doing about rng?
07:17:33 <heycam> CM: should we still include the dtd in the appendix?
07:17:44 <heycam> CL: i guess we should; we should add some wording about problems with dtds, non-namespace-aware, etc.
07:18:06 <heycam> ... we should fix the non-deterministic problems and other things that were identified
07:18:21 <heycam> ... add wording to say that if you want to validate including rdf etc., then suggest using rng
07:18:43 <heycam> CM: we might want to rewrite some of the text in extend.html
07:18:52 <heycam> CL: where's the rng coming from?
07:19:06 <heycam> ... i think it would be better to start with the 1.2T rng and add/remove things
07:19:14 <heycam> ED: There's an rng for 1.1, not sure how correct it is
07:19:19 <heycam> CL: i don't think it's quite correct
07:19:25 <ed> s/1.1/1.2 full/
07:19:28 <heycam> ... the other option is to take the dtd and convert it to rng
07:19:43 <heycam> ... so i think it would be best to start from 1.2T and add the 1.1 features
07:19:54 <ChrisL> a trang conversion is probably not going to be very readable
07:20:20 <heycam> ACTION: Chris to make RNG for 1.1 based on the 1.2T one
07:20:20 <trackbot> Created ACTION-2516 - Make RNG for 1.1 based on the 1.2T one [on Chris Lilley - due 2009-04-15].
07:22:45 <heycam> CM: there are still a few outstanding 1.1 errata that need working on
07:23:13 <heycam> ED: it would be useful if people could finish those off, and talk about them after next week
07:23:33 <heycam> Topic: Color module
07:24:01 <heycam> CL: there has been a question asked of me about why we support rendering-intent
07:24:07 <heycam> ... my answer was because the ICC spec has rendering intent
07:24:20 <heycam> ... people have pushed back and said that it's probably going away from the next ICC spec
07:24:26 <heycam> ... and many profiles have only a single table
07:24:39 <heycam> ... we have to say what happens if the user requests a rendering intent and there isn't a table for it
07:24:52 <heycam> ... i will be discussing with the openicc people at libre graphics some of the options for that, but that's a new issue
07:25:01 <heycam> ... at minimum it needs to go into the spec as an issue
07:25:08 <heycam> ... hopefully i can add some text to describe fallback
07:25:24 <heycam> AG: i can also talk to some people here to see what fallback to use
07:25:59 <heycam> ... i got a group of people together within cisra to discuss the color module, and from that review we felt that it wasn't targetting anything specific
07:26:26 <heycam> ... i went back and talked to some other cisra people, and we figured that with the current features that are in the color module, it's best targetted towards office printing
07:26:31 <heycam> ... not sure if that's the original intent of the spec
07:26:38 <heycam> CL: it should cover that, but i don't think it should be specific to it
07:26:50 <heycam> AG: it does cover everything from regular web authoring up to office printing
07:26:55 <heycam> ... it's probably not sufficient for high end printing
07:27:02 <heycam> ... we should specify what areas we are intending to target
07:27:16 <heycam> CL: it would be helpful if you could let us know what is missing for high end printing
07:27:26 <heycam> ... not necessarily to put it into the spec, but just to know
07:27:56 <heycam> AG: in terms of the current spec being useful for office printing, one feature we think is missing is "preserve black"
07:28:16 <heycam> ... where you'd be able to say that RGB black (or CMYK black) would be preserved as black at the printer
07:28:23 <heycam> CL: is that different from black point compensation?
07:28:37 <heycam> ... if i have rgb(0.0001, 0, 0) is that also black?
07:28:50 <heycam> ... black point preservation says what really is black, given the surroundings
07:29:22 <heycam> AG: this is basically for text. if you specify some text as black, you'd want to preserve that so that at the end when printing, it doesn't use CMY to make up the colour. but uses the black ink
07:29:30 <heycam> CL: so you're using black as a spot colour, and saying not to separate it
07:29:31 <heycam> AG: yes
07:29:36 <heycam> ... the other area where this is useful is for fonts
07:29:53 <heycam> ... because if you pull out a font that's a bitmap, you could say preserve black on the bitmap so that they don't get colour converted
07:30:06 <heycam> ... otherwise you still might get a browny colour out at the end for your text
07:30:15 <heycam> CL: but you still want it to be optional?
07:30:24 <heycam> ... e.g. if you're matching up with other black parts of the image
07:30:34 <heycam> AG: haven't thought that far ahead
07:31:03 <heycam> ... if you have line art between the text, you might want to use preserve black on the line art too
07:31:25 <heycam> ... some of these guys would be happy to join a call to discuss things that are missing
07:31:53 <heycam> ... we're still doing some more review on it, we'll get comments in in a week or two
07:32:09 <heycam> Topic: Transforms module
07:32:27 <heycam> s/Topic: Transforms module/CL: i started looking at a global default for icc profiles/
07:32:35 <heycam> ... it's fairly easy to do, not sure it gains you much
07:32:55 <heycam> AG: the other thing is that icc profiles are referenced by name. is it possible to reference them by id?
07:33:24 <heycam> CL: what does the id look like in the spec?
07:33:35 <heycam> ... if there's a big complicated string, we'd only want to use that once in a document
07:33:39 <anthony> http://dev.w3.org/SVG/modules/color/master/SVGColor.html
07:34:09 <ChrisL> not *that* spec :)
07:34:28 <ChrisL> http://www.color.org/ICC1V42.pdf
07:36:01 <heycam> CL: the profile's unique id is an MD5 hash
07:36:11 <heycam> ... using that everywhere in a document wouldn't be nice
07:36:46 <ChrisL> ok so the short readable name instgead of a n MD5 unreadable thing is much nicer
07:37:45 <heycam> AG: 'local' is optional too
07:38:13 <heycam> Topic: Transforms module
07:38:28 <heycam> AG: i was reading through the conformance criteria section in 1.2T
07:38:43 <anthony> "If using features defined in SVG Full, an extension must not redefine the syntax of the syntax of those features."
07:38:52 <anthony> "An extension must not redefine the semantics of any existing SVG element or attribute."
07:39:25 <heycam> AG: we'd need to use unique names, we can't redefine semantics of existing attribute names
07:39:43 <ChrisL> (found the unique name thing - its section 7.2.18 Profile ID field (Bytes 84 to 99))
07:40:09 <anthony> http://www.w3.org/TR/2009/WD-SVG-Transforms-20090320/#transform-list-extensions
07:40:35 <heycam> CM: i assume it's more for 3rd party extensions rather than restricting how the WG can extend the language
07:40:44 <heycam> AG: i'd like to start discussing some of the issues that were raised
07:43:16 <anthony> ISSUE-2233?
07:43:16 <trackbot> ISSUE-2233 -- adopt the syntax for CSS Transforms -- RAISED
07:43:16 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2233
07:43:53 <heycam> AG: here dino asks why we dropped translateX/Y/Z etc.
07:44:19 <heycam> ... there's no real cost in having them in there, is it worth dropping them or keeping them?
07:44:23 <heycam> DS: i don't think it makes a big deal either way
07:45:06 <heycam> ... i think i was the one who originally raised the issue about adding too many transform items, but if there's a plausible story for them making it easier for authors, i'm all for it
07:45:57 <heycam> CM: the cognitive cost of having both translate(5) and translateX(5) doing the same thing probably isn't too great
07:46:08 <heycam> JW: my concern was about implementation strategies and optimising memory usage
07:46:45 <heycam> ... rather than having 16 values for some of the transforms you could cut it down to 1 or 2 quite often
07:47:09 <heycam> ... there's probably enough in there that implementations would have to deal with that complexity anyway, so perhaps it's not a concern
07:48:06 <heycam> CM: do implementations keep around only a single value for transform="scale(4)" at the moment, rather than storing all 6 values for 2d transforms? 
07:48:16 <heycam> JW: the moz code at the moment stores the full matrices
07:48:33 <heycam> AG: i'd imagine a lot of transform pipelines would be like that
07:48:53 <heycam> JW: was thinking of implementing it with an operator overload kind of thing, with classes for the different types
07:48:58 <heycam> ... but that's probably a bad strategy anyway ;)
07:49:33 <heycam> AG: if you do have translateX/Y/Z, do we keep the current translate() transform item as is?
07:49:37 <anthony> translate(<tx> [<ty> [<tz>]])
07:49:48 <heycam> ... would we still allow translate() to do a 3d translate?
07:50:14 <heycam> CM: in the css proposal do they only allow two parameters to translate()?
07:50:21 <heycam> AG: yes, and have an additional translate3d()
07:50:48 <heycam> CM: maybe they did that to avoid trampling on existing svg transform items
07:51:17 <heycam> AG: they have no optional components for translate3d(), but keep translate() the same as svg's
07:51:34 <heycam> DS: we should have a call with dino to discuss these instead of guessing at intentions
07:52:56 <heycam> ACTION: Anthony to mail dino CCing public-fx to get him to join an SVG call to discuss transforms
07:52:56 <trackbot> Created ACTION-2517 - Mail dino CCing public-fx to get him to join an SVG call to discuss transforms [on Anthony Grasso - due 2009-04-15].
07:53:03 <shepazu> public-fx
07:57:48 <Zakim> -ed
07:57:49 <Zakim> -ChrisL
07:57:52 <Zakim> -heycam
07:57:56 <Zakim> -Doug_Schepers
07:58:04 <Zakim> -anthony
07:58:06 <Zakim> -[IPcaller]
07:58:06 <Zakim> GA_SVGWG()2:30AM has ended
07:58:07 <Zakim> Attendees were [IPcaller], anthony, heycam, Doug_Schepers, ed, ChrisL
07:58:16 <heycam> RRSAgent, make minutes
07:58:16 <RRSAgent> I have made the request to generate http://www.w3.org/2009/04/08-svg-minutes.html heycam
08:00:32 <heycam> RRSAgent, bye
08:00:32 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2009/04/08-svg-actions.rdf :
08:00:32 <RRSAgent> ACTION: Doug to contact AT vendors about SVG accessibility [1]
08:00:32 <RRSAgent>   recorded in http://www.w3.org/2009/04/08-svg-irc#T06-59-29
08:00:32 <RRSAgent> ACTION: Chris to make RNG for 1.1 based on the 1.2T one [2]
08:00:32 <RRSAgent>   recorded in http://www.w3.org/2009/04/08-svg-irc#T07-20-20
08:00:32 <RRSAgent> ACTION: Anthony to mail dino CCing public-fx to get him to join an SVG call to discuss transforms [3]
08:00:32 <RRSAgent>   recorded in http://www.w3.org/2009/04/08-svg-irc#T07-52-56