W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, 15 December 2008 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 16 Dec 2008 08:05:52 +1100
To: public-svg-wg@w3.org
Message-ID: <20081215210552.GA8738@arc.mcc.id.au>



      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

15 Dec 2008

   See also: [2]IRC log

      [2] http://www.w3.org/2008/12/15-svg-irc


          shepazu, [IPcaller], ed, heycam, anthony, ChrisL




     * [3]Topics
         1. [4]Sydney f2f
         2. [5]svg 1.1 errata
         3. [6]clip path erratum
         4. [7]1.1 test suite bug
         5. [8]name of SVG Tiny 1.2
         6. [9]SVG 1.1 test suite bug
     * [10]Summary of Action Items

   <trackbot> Date: 15 December 2008

   <shepazu> that's annoying

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

     [11] http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/

   <ed> scribeNick: ed

Sydney f2f


     [12] 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


     [13] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#propogation-of-rotation-text


     [14] 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

   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

   <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


     [15] 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

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

   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
   ... i think if this issue had come up earlier it might've been more
   ... 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

   <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
   ... so revision numbers didn't matter

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

     [17] 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
   ... i don't know if it's hard to copy them over without the history

   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

   <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

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

Summary of Action Items

   [NEW] ACTION: Cameron to summarise last telcon's discussions on
   svg-in-html and reply to the existing thread [recorded in
   [NEW] ACTION: Chris to respond to the bugzilla bug on the incorrect
   reference image [recorded in
   [NEW] ACTION: Erik to move the 1.1 tests to public cvs, checking
   diffs against the corresponding 1.2T tests [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [23]scribe.perl version 1.133
    ([24]CVS log)
    $Date: 2008/12/15 21:01:34 $

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [24] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [25]http://dev.w3.org/cvsweb/~checkout~/2002

     [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/arr/err/
Succeeded: s/becoming/being/
Succeeded: s/1.2T/1.1 and then diff the 1.2T ones against these/
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
Found ScribeNick: ed
Found Scribe: Cameron
Found ScribeNick: heycam
ScribeNicks: ed, heycam
Default Present: shepazu, [IPcaller], ed, heycam, anthony, ChrisL
Present: shepazu [IPcaller] ed heycam anthony ChrisL

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 15 Dec 2008
Guessing minutes URL: [26]http://www.w3.org/2008/12/15-svg-minutes.html
People with action items: cameron chris erik

     [26] http://www.w3.org/2008/12/15-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   End of [27]scribe.perl diagnostic output]

     [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 15 December 2008 21:06:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 15 December 2008 21:06:55 GMT