See also: IRC log
<trackbot> Date: 08 April 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
DS: not much to show yet, thought i'd get something going
<shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
DS: i'm going to start by integrating that embedding document i once wrote
ED: sounds good
<shepazu> http://www.schepers.cc/svg/blendups/embedding.html
DS: also how to extend svg,
starting with what we had in 1.2T
... i'll put in whatever hooks cameron needs for doing the
tables of attributes and elements
CL: did how we do attributes change recently?
CM: still experimenting, once the build scripts are finalised i'll mail the list with details
<shepazu> http://www.w3.org/TR/SVGTiny12/conform.html#ConformingSVGEncoding
[doug reads out D.7]
CL: nice that that wording is in there
DS: does the current svg in html proposal violate that?
CL: the intention would be not to violate that, not sure about the current proposal
DS: i don't think it does violate
it
... 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
... a question about svg in an <img> element
... what if you have svg referenced from html <img>
... <object> has .contentDocument
<ChrisL> script in svg wich is in an image, or script somewhere else getting at svg in an image through script?
DS: does <img>?
... i'm kind of thinking that we might say no
ED: i don't think that would work, at least in opera 10
DS: should it?
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.
... since it doesn't allow scripting inside the referenced
document, that's why we chose to leave out the interface
CL: but why prevent accessing the document from outside?
DS: i think from a security and efficient viewpoint, it might be better not to get at the contents at all
ED: my question is, what would happen if you inserted a <script> inside the referenced document?
CL: i'm talking about getting to
the document at all. whether it's readonly or read-write is a
separate question.
... 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>
DS: if you reference using
<object>, <embed>, etc., you already have that
capability
... we're talking about one particular embedding scenario that
walls it off more
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>
DS: the canvas api operates on <canvas> and not <img>, right?
ED: yes
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)
... so with <img> you can't access the DOM from the
outside
CL: if you can't access the DOM from inside or the outside, do you need to build a DOM at all?
DS: text
CL: might be an accessibility concern if an AT can't access the text as a DOM
CM: perhaps the AT uses privileged methods to get at the DOM, not just standard script in the web page
DS: in the html wg we're
discussing accessibility of canvas
... 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
ED: i would prefer in that case
to have specialised access for ATs
... 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
... but you're just prevented from accessing it in script
... i don't think it'd be a problem to expose that information
to ATs
... i'd have to check how we integrate with ATs, though, but i
don't think it'd be a problem
... i agree that it'd be useful for such tools to be able to
access that information inside
[discussions about getting AT vendors involved in helping with SVG accessibility speccing]
<scribe> ACTION: Doug to contact AT vendors about SVG accessibility [recorded in http://www.w3.org/2009/04/08-svg-minutes.html#action01]
<trackbot> Created ACTION-2515 - Contact AT vendors about SVG accessibility [on Doug Schepers - due 2009-04-15].
DS: i wonder if much of the challenge for them is in drilling in to embedded DOMs (e.g., via <object>)
[discussions of appropriate title/desc]
DS: this'd be for the svg semantics spec (which would deal with aria, too)
ED: another thing for the integration spec would be css fonts and web fonts, whether or not scripts should run in referenced svg fonts
CL: if an svg has an @font-face,
which points back to the same document; if that document has
script, should it run?
... how about if they're in different documents?
... not sure where the line lies
DS: some of these trickier decisions fall out from higher level decisions
No telcons next week.
ED: what's the status on the scripts?
http://mcc.id.au/temp/struct.html
CM: changes since last update are the interfaces at the bottom of that
http://dev.w3.org/SVG/profiles/1.1F2/master/svg.idl
CM: the idl file is using javadoc-style comments now
[people are happy with javadoc-style comments in the idl]
<ChrisL> (discussion about svg)
CL: what are we doing about rng?
CM: should we still include the dtd in the appendix?
CL: i guess we should; we should
add some wording about problems with dtds, non-namespace-aware,
etc.
... we should fix the non-deterministic problems and other
things that were identified
... add wording to say that if you want to validate including
rdf etc., then suggest using rng
CM: we might want to rewrite some of the text in extend.html
CL: where's the rng coming
from?
... i think it would be better to start with the 1.2T rng and
add/remove things
ED: There's an rng for 1.2 full, not sure how correct it is
CL: i don't think it's quite
correct
... the other option is to take the dtd and convert it to
rng
... so i think it would be best to start from 1.2T and add the
1.1 features
<ChrisL> a trang conversion is probably not going to be very readable
<scribe> ACTION: Chris to make RNG for 1.1 based on the 1.2T one [recorded in http://www.w3.org/2009/04/08-svg-minutes.html#action02]
<trackbot> Created ACTION-2516 - Make RNG for 1.1 based on the 1.2T one [on Chris Lilley - due 2009-04-15].
CM: there are still a few outstanding 1.1 errata that need working on
ED: it would be useful if people could finish those off, and talk about them after next week
CL: there has been a question
asked of me about why we support rendering-intent
... my answer was because the ICC spec has rendering
intent
... people have pushed back and said that it's probably going
away from the next ICC spec
... and many profiles have only a single table
... we have to say what happens if the user requests a
rendering intent and there isn't a table for it
... i will be discussing with the openicc people at libre
graphics some of the options for that, but that's a new
issue
... at minimum it needs to go into the spec as an issue
... hopefully i can add some text to describe fallback
AG: i can also talk to some
people here to see what fallback to use
... 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
... 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
... not sure if that's the original intent of the spec
CL: it should cover that, but i don't think it should be specific to it
AG: it does cover everything from
regular web authoring up to office printing
... it's probably not sufficient for high end printing
... we should specify what areas we are intending to target
CL: it would be helpful if you
could let us know what is missing for high end printing
... not necessarily to put it into the spec, but just to
know
AG: in terms of the current spec
being useful for office printing, one feature we think is
missing is "preserve black"
... where you'd be able to say that RGB black (or CMYK black)
would be preserved as black at the printer
CL: is that different from black
point compensation?
... if i have rgb(0.0001, 0, 0) is that also black?
... black point preservation says what really is black, given
the surroundings
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
CL: so you're using black as a spot colour, and saying not to separate it
AG: yes
... the other area where this is useful is for fonts
... 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
... otherwise you still might get a browny colour out at the
end for your text
CL: but you still want it to be
optional?
... e.g. if you're matching up with other black parts of the
image
AG: haven't thought that far
ahead
... if you have line art between the text, you might want to
use preserve black on the line art too
... some of these guys would be happy to join a call to discuss
things that are missing
... we're still doing some more review on it, we'll get
comments in in a week or two
CL: i started looking at a global
default for icc profiles
... it's fairly easy to do, not sure it gains you much
AG: the other thing is that icc profiles are referenced by name. is it possible to reference them by id?
CL: what does the id look like in
the spec?
... if there's a big complicated string, we'd only want to use
that once in a document
<anthony> http://dev.w3.org/SVG/modules/color/master/SVGColor.html
<ChrisL> not *that* spec :)
<ChrisL> http://www.color.org/ICC1V42.pdf
CL: the profile's unique id is an
MD5 hash
... using that everywhere in a document wouldn't be nice
<ChrisL> ok so the short readable name instgead of a n MD5 unreadable thing is much nicer
AG: 'local' is optional too
AG: i was reading through the conformance criteria section in 1.2T
<anthony> "If using features defined in SVG Full, an extension must not redefine the syntax of the syntax of those features."
<anthony> "An extension must not redefine the semantics of any existing SVG element or attribute."
AG: we'd need to use unique names, we can't redefine semantics of existing attribute names
<ChrisL> (found the unique name thing - its section 7.2.18 Profile ID field (Bytes 84 to 99))
<anthony> http://www.w3.org/TR/2009/WD-SVG-Transforms-20090320/#transform-list-extensions
CM: i assume it's more for 3rd party extensions rather than restricting how the WG can extend the language
AG: i'd like to start discussing some of the issues that were raised
<anthony> ISSUE-2233?
<trackbot> ISSUE-2233 -- adopt the syntax for CSS Transforms -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2233
AG: here dino asks why we dropped
translateX/Y/Z etc.
... there's no real cost in having them in there, is it worth
dropping them or keeping them?
DS: i don't think it makes a big
deal either way
... 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
CM: the cognitive cost of having both translate(5) and translateX(5) doing the same thing probably isn't too great
JW: my concern was about
implementation strategies and optimising memory usage
... rather than having 16 values for some of the transforms you
could cut it down to 1 or 2 quite often
... there's probably enough in there that implementations would
have to deal with that complexity anyway, so perhaps it's not a
concern
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?
JW: the moz code at the moment stores the full matrices
AG: i'd imagine a lot of transform pipelines would be like that
JW: was thinking of implementing
it with an operator overload kind of thing, with classes for
the different types
... but that's probably a bad strategy anyway ;)
AG: if you do have translateX/Y/Z, do we keep the current translate() transform item as is?
<anthony> translate(<tx> [<ty> [<tz>]])
AG: would we still allow translate() to do a 3d translate?
CM: in the css proposal do they only allow two parameters to translate()?
AG: yes, and have an additional translate3d()
CM: maybe they did that to avoid trampling on existing svg transform items
AG: they have no optional components for translate3d(), but keep translate() the same as svg's
DS: we should have a call with dino to discuss these instead of guessing at intentions
<scribe> ACTION: Anthony to mail dino CCing public-fx to get him to join an SVG call to discuss transforms [recorded in http://www.w3.org/2009/04/08-svg-minutes.html#action03]
<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].
<shepazu> public-fx
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/violated/violate/ Succeeded: s/1.1/1.2 full/ Succeeded: s/Topic: Transforms module/CL: i started looking at a global default for icc profiles/ Found Scribe: Cameron Found ScribeNick: heycam Default Present: [IPcaller], anthony, heycam, Doug_Schepers, ed, ChrisL Present: [IPcaller] anthony heycam Doug_Schepers ed ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0016.html Found Date: 08 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/08-svg-minutes.html People with action items: anthony chris doug[End of scribe.perl diagnostic output]