SVG Working Group Teleconference -- 15 Dec 2008

<trackbot> Date: 15 December 2008

<shepazu> that's annoying

<shepazu> http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/

<ed> scribeNick: ed

Sydney f2f

<shepazu> http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/results

AG: please register if you're coming

ED: location?

AG: probably manly

svg 1.1 errata

<anthony> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#propogation-of-rotation-text

http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/errata/errata.xml.diff?r1=1.16&r2=1.17&f=h

CM: some small things

<ChrisL> CM: </svg>;

<ChrisL> is wrong

CL: the included file seems fine, but the inline example is wrong

<ChrisL> trailing semicolon is not in the source that is included; must be in the errata

ED: is it correct that it maps rotate to characters and not to glyphs?

AG: yes

CL: the spec tells you what to do for those cases, important for ligatures for example, you skip values if you do a ligature

<ChrisL> particularly important to avoid off-by-one errors with optional ligatures

<heycam> propogation -> propagation

<heycam> the links to the rotate attribute should have single quotes around them (like the element links)

<heycam> most of the links have an unwanted trailing space within the link

<ChrisL> yup, thats right. does not affect tiny

<heycam> ED: is this in tiny?

<heycam> AG: no, tiny doesn't have positioning attributes on tspans etc.

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

ED: is there any example with both rotate and x/y positioning at the same time?

AG: no

ED: i'm wondering if it's defined in what order they're applied, if it makes any difference

CM: would it make any difference?

ED: wouldn't think so

"the the (orange)" -> "the (orange)"

ED: it says "supplemental rotation", so it seems to be pretty clear
... might be easier to read if the paragraph describing the rotations is split into a list

CM: maybe a list item per element

AG: ok should be easy

ED: optionally you could be the same text inside the test, as the test description
... is it informative or normative?

AG: informative

ED: probably should note it as informative
... there might some generic statement that says that all examples are informative

<ChrisL> +1

ED: should we move it to proposed?

CM: do you have an svg version of the rotation diagram?

AG: no i might make one

ED: pending these changes we can move it to proposed

AG: batik and opera do the same thing, which is not propagating the rotation into tspans
... and not onto the text after a child tspan
... in example 5, the last word "rotation" doesn't have any characters rotated in batik/opera

ED: for us it'd be nice so we don't have to do two different things for rotation [since it's different in tiny]
... i'd like to hear jwatt's comments
... have you tested firefox?

AG: yes they don't rotate any of the characters

CM: what made us choose to do it this way?

AG: in tiny, if there are fewer rotations than characters, it doesn't say what to do if there's a tspan
... so the erratum makes 1.1 align with tiny

CL: aligns and extends

CM: it was undefined in 1.1?

AG: yes

ED: it's not interoperable at the moment, so hopefully this will make it usuable
... don't know if we had many 1.2T tests for text rotation

CL: it'd be a good test for 1.1e2
... more likely to get fixed in implementations if there are tests

CM: are there tests associated with this erratum?

AG: no but i could take the tspan05 example and turn it into a test
... change the text colour to green, with expected rotation characters in red underneath

ED: should probably make all errata tests into proper test suite tests for a release later

clip path erratum

ED: more feedback from thomas?

DS: he is arguing from the point of view of implementing, but to me it is more important how useful the feature is
... and it's not a burden to implement it the way we've described
... he argues that it's hacky/ugly, but i don't think he's substantiated that

<ChrisL> I agree with Doug

ED: i'd agree that it would put a burden on implementations to change things, but it's not a big burden

DS: i mean an undue burden. any change needs effort.
... he seems to be claiming that batik is doing it a certain way, turning clip paths into masks

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2008Dec/0041.html

CM: i think that was part of his argument that clip paths are more like pixel operations

DS: i don't see a conflict with tying visibility to clipping, but he does

CL: i think it's consistent to tie the visible* values to clipping

ED: i'd agree
... it would not be a good idea to introduce more pointer-events values
... introducing new elements could be an option in the future

DS: i think it's worth the little bit of work for implementors to do it this way

CL: it's unspecified at the moment, some implementations have to change, we think we've changed it the right way

DS: if we change this, how hard would it be to change the behaviour in batik?

CM: i think not hard, thomas has created a patch that unconditionally (irrespective of pointer-events) clips events

ED: so the only thing missing from batik would be treating the visible* values differently
... same change for firefox

DS: and safari would have to change to clip by default, and doesn't clip when pointer-events has particular values

CL: has safari implemented it differently, or not at all?

ED: they do clipping, but perhaps the same as batik currently

<shepazu> ran out of skype credit.... will be back in a moment

ED: i don't think it's a bad change

CL: i think we should move it to proposed

https: //issues.apache.org/bugzilla/show_bug.cgi?id=46289

RESOLUTION: Move this clip path events erratum to proposed

1.1 test suite bug

name of SVG Tiny 1.2

<ChrisL> It has been suggested that Tiny 1.2 should be called Core 1.2

DS: an issue with the name of the SVG Tiny 1.2 spec has come up
... it's been suggested that we name it SVG 1.2 Core, it being the core language that 1.2 modules go on top of

CL: we've already said it's the core of the language, calling it Core 1.2 is reasonably consistent
... and when we come up with Core 2.0 it's consistent
... otoh, the name SVGT has a bit of traction
... getting rid of that term would be a problem

DS: we'd have to hear from the two main mobile vendors

AG: i agree with chris, can see both sides of the coin

DS: i'm the same way, fairly ambivalent
... i wonder if people might look at SVG Core and say "oh, there's something new" rather than as svg tiny
... people might think svg tiny is old news
... otoh, calling it Core sends a certain message to the browser vendors that we think this is the core of the language, which some of them have objected to in the past

AG: be good to get feedback from mobile and desktop implementors

ED: practically, doing the name change would mean going through the spec and changing all instances of the name
... other specs that reference it?

DS: might create confusion in the marketplace about whether svg is implemented/used
... i think if this issue had come up earlier it might've been more feasible
... we could ask ikivo/bitflash what they think about it

CM: they probably have promotional material already published with the current name

DS: i'm inclined to say that unless we get buy-in from bitflash/ikivo, we keep the name as is
... an appropriate time to have done this might've been when we went back to LC

ED: we'd have to decide before going to rec. there are 3 more days of AC review?
... after those days what happens?

DS: planning on publishing on friday
... i'll email bitflash/ikivo

ED: my opinion would be that it would cause confusion rather than unity or anything

SVG 1.1 test suite bug

ED: we got a bug report
... are we using the bugzilla?

DS: if people are comfortable raising bugs that way, then we should keep it

CL: preferable to people adding it to our tracker

ED: this particular test case does have an incorrect reference image, i think
... i don't think it's news; we probably have it in the old tracker, along with other test suite bugs
... we should track it in the new tracker and fix it as part of releasing the 1.1e2 spec
... having someone respond is a good idea

CL: i'll respond

<scribe> ACTION: Chris to respond to the bugzilla bug on the incorrect reference image [recorded in http://www.w3.org/2008/12/15-svg-minutes.html#action01]

<trackbot> Created ACTION-2381 - Respond to the bugzilla bug on the incorrect reference image [on Chris Lilley - due 2008-12-22].

CL: why is the reference image incorrect? what makes it wrong?

ED: not sure exactly, the link he gives (blow-by-blow) is correct

<ChrisL> ok so why is the reference image wrong here?

<ChrisL> batik uses a series of box blurs?

ED: i'd guess that batik just generated it incorrectly or that it was an incorrect patch file

<ChrisL> could be a buggy patch file

CL: i'll look into that

ED: until we have the 1.1 test suite moved over, it's difficult to do the fixes
... any status update on that?

DS: we decided not to do it, since we need to change the tests anyway
... so revision numbers didn't matter

<ed> http://www.w3.org/Graphics/SVG/WG/track/actions/2373 ?

CM: didn't we say that we should do it to keep the cvs logs?

CL: i'd imagine the best thing would be to port the 1.2T copies
... using the 1.1 <-> 1.2T test name correspondence table
... checking them in with cvs revision 1.1 files
... we shouldn't lose the fixes we made in 1.2T

ED: i have a feeling most of those fixes were for xml:id and not much else
... e.g. tiny things that weren't in 1.1
... i could be wrong but that's my feel of it
... things like changing percentages to [0,1] ranges for gradients, minor things like that
... might be a good idea to check
... since we have that name correspondence table, the files could be diffed to see if there are major changes
... shouldn't take too long

<ChrisL> yes i agree a pairwise diff would eb good looking for non-obvious changes

ED: for the moving over would we create new files and lose the history?
... i don't know if it's hard to copy them over without the history then

CL: are we copying 1.1? or 1.2T and changing them back?

ED: i'd like to take the 1.1 and then diff the 1.2T ones against these ones that have appropriate changes from the 1.1 versions

<scribe> ACTION: Erik to move the 1.1 tests to public cvs, checking diffs against the corresponding 1.2T tests [recorded in http://www.w3.org/2008/12/15-svg-minutes.html#action02]

<trackbot> Created ACTION-2382 - Move the 1.1 tests to public cvs, checking diffs against the corresponding 1.2T tests [on Erik Dahlström - due 2008-12-22].

AG: are we using the new test template when we move them over?

ED: that'd be a followup thing i guess

CL: i'd copy and include in the commit log a pointer to the old file

<scribe> ACTION: Cameron to summarise last telcon's discussions on svg-in-html and reply to the existing thread [recorded in http://www.w3.org/2008/12/15-svg-minutes.html#action03]

<trackbot> Created ACTION-2383 - Summarise last telcon's discussions on svg-in-html and reply to the existing thread [on Cameron McCormack - due 2008-12-22].

- DRAFT -

SVG Working Group Teleconference

15 Dec 2008

Attendees

Contents