SVG Working Group Teleconference -- 08 Sep 2010

<trackbot> Date: 08 September 2010

last call comments on SVG1.1SE

<ChrisL> Scribe: Chris

<ChrisL> Scribenick: ChrisL

action-2812?

<trackbot> ACTION-2812 -- Erik Dahlström to find the test case, commit it and make some proposed wording -- due 2010-07-13 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2812

<ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/filter-feconvolvematrix-bias-ISSUE-2812.svg

ED: Found one test and an image
... extended the test with colour-interpolation-filters. Seems in inkscape 0.47 that al three are the same

CL: What is the correct result?

ED: That is what Jasper is asking

<ed> ISSUE-2335?

<trackbot> ISSUE-2335 -- Last Call Comment: Clarify feConvolveMatrix bias property -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2335

ED: What does firefox do with the bias?
... not much used so cost to change as a result of clarifications is low

(checking inkscape 0.48)

ED: Opera and Firefox same on bias
... In batik it drew nothing
... color-interpolation-filters should affect the result, so inkscape 0.48 is wrong

CL: Often filter implementations seem to not get the colour space right for calculations (at least, at first) until they see what a difference it makes

batik svn says 'rendering document failed' on that test

ED: ASV3 does same as Opera and Firefox

CL: I extended the test to add an explicit bias="0.0"
... checking in now

http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/filter-feconvolvematrix-bias-ISSUE-2812.svg

JW: What is the use case here

ED: For example comparing two images by subtraction, bias moves it from being centred on zero (and clipped) to centred on 0.5

DS: Maybe aske DDailey

CC: Ask Vincent Hardy

<scribe> ACTION: erik to ask Vincent Hardy and David Dailey about bias and ISSUE-2335 [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action01]

<trackbot> Created ACTION-2859 - Ask Vincent Hardy and David Dailey about bias and ISSUE-2335 [on Erik Dahlström - due 2010-09-15].

DS: Trying test in Safari and Chrome nightlies

CL: Of the implementations that do color-interpolation-filters and do bias, they all get the same result and follow the spec.

DS: Chrome does not implement color-interpolation-filters but they do implement bias

SVG 2.0 and audio, video

CL: SVG 1.2T audio and video has good timing, which is an advantage for synchronisation compared to html5 audio and video, but our dom apis suck. A good first step would be the 1.2T markup, with timing and synchronisation, but with the HTML5 apis

ED: What about the source elements and fallback?
... fallback formats in 1.2T not as good as the html5 ones, we should adopt them

CC: Microsoft asked me at SVG Open about the differences between html5 and svg video

s/soure/source/

CC: I had five points of key differece (looks for notes)

<cyril> CC: separation of document timeline from media timeline

<cyril> CC: ability to start/stop the media timeline at specific time in the document timeline

<cyril> CC: ability to start/stop the media timeline at a specific time in the media timeline (SMIL clipBegin/clipEnd)

<cyril> CC: explicit syncing of media timelines

CL: For example syncing a video stream to an audio stream

<cyril> CC: ability to receive events from the media (Media Access Events)

DS: Would like to see a more detailed comparison of markup and APIs

CC: People are scared of smil, the timing model when you restrict it to these 5 points is not complex and is already in flash, mpeg4 etc is is needed functionality

DS: Simon Fraser said it was tricky to sync multimedia due to platform concerns. Animation is very different from audio and video sync

CC: yes, timing and animation are quite different. Also audio and video typically handled by a decoder or an external system library

DS: Constraints are on the multimedia engine
... Would prefer to discuss this in the FX task force because Simon is there

<cyril> CC: the use of time containers (nested ...) is complex

DS: Not totally convinced SVG should have audio and video

CC: HTML5 has audio, video and track
... SVG has audio video and animation

CL: Want to see explicit support for subtitling in SVG video so its clear how to add it

<cyril> s/CL;/CL:§

DS: Want to see that in the platform

<shepazu_> DS: I want to see subtitling on the web platform, but I want it to be the same as is used in HTML

DS: Its important to have audio and video content in SVG but using the HTML5 audio and video its not much of an authoring burden and the api is nice

CC: f the video is only in html, is it flexible enough? Can you make a video paint server for example?

ED: Yes you could, depends on how its implemented, need to wrap in foreign object, better to have a video element as it removes two steps of indirection

<cyril> s/CC:f the/CC:if the/

CL: Yes there is no need to invoke an unused box model for a video elemetn (or indeed audio)

DS: Need to look more at foreignObject

s/Ned/Need/

DS: We need to get more input from the browser implementors on this

ED: Opera experience is that SVGT1.2video is much more efficient than HTML5 video wrapped in foreign object, for svg-with-video

Markers

<shepazu_> I don't want SVG to add video and audio unless it is done in a compatible way to HTML5 (which is what we've been talking about) and unless we have buy-in from all the major browser vendors

<shepazu> s/because Simon is there//because Simon, DSinger, Jack Jansen, and other implementers with specific multimedia expertise are there/

<shepazu> scribenick: shepazu

ChrisL: [gives background]
... GKS had the concept of fill, stroke, and marker...
... it was pivotal in the 1970s in framing the language of 2d graphics
... when SVG added it, it seemed obvious to talk about it in those terms
... but if you look at the use of markers, people use markers, or they use paths with fill and stroke...
... markers are on points of particular interest, rather than on the geometry of the path beziers
... so, I feel it was a mistake to add markers in this way...
... you can have markers on markers, etc. which isn't useful
... I think it might be a good idea to deprecate markers and add a new, more useful equivalent
... for example, allowing them to dispatch events rather than just being part of the rendering model
... I started to make a proposal for "polymarkers"...
... which would be like polyline, takes a list of points
... but that's not good enough, because you can't put events on individual makers
... so instead, I think it would be better to have a marker container, where each marker is an element, which can have an id, can be animated and interactive

jwatt: so you couldn't reuse a marker?

ChrisL: you could use a "use"...
... haven't thought through the exact mechanism
... could have 'd' attribute, but that's not good enough
... the other option is having it more like a <use>
... so you can have multiple colors, and multiple instantiations
... if you wanted them to be identical, the container could have the href that points to the marker

jwatt: 2 questions
... when the path that you're marking....

ChrisL: no, you're not putting them on a path, they are separate

jwatt: ok, as an author, I may draw a path that I want to have markers in sync

ChrisL: right, but if you want to have straight lines, that's easy... but if have a smooth curve, you always have to sync manually

jwatt: I've been thinking about this, too....
... rather than have markers at the vertices between the segments, have a property that says, "every x unit along the path"

ChrisL: or "I want x number of markers evenly placed"

shepazu: or points at a certain length along a path

ChrisL: the disadvantage to that is that it only extends our current model, with lack of addressability

break for lunch

<ed> [back from lunch]

<scribe> ACTION: ChrisL to write up different proposals for markers [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action02]

<trackbot> Created ACTION-2860 - Write up different proposals for markers [on Chris Lilley - due 2010-09-15].

F2F schedule

ed: we're meeting at TPAC; if you haven't registered, you should do so soon

http://lists.w3.org/Archives/Member/chairs/2010JulSep/0040.html

ed: what about the next F2F?
... TPAC is in November

anthony: we could do Sydney in February

ed: or New Zealand, where heycam will be

[discussion about NZ]

it would get us folks from Australia, like heycam, Brian Birtles, Alex Danilo... and hopefully ROC could join for a day or 2

ChrisL: where would it be? would mozilla host?

jwatt: there is a small office in Auckland, not big enough to host, but we could talk about getting facilities for a meeting.... I'll have to ask

<scribe> ACTION: jwatt to investigate Mozilla hosting an SVG WG F2F in Auckland, NZ in February/March [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action03]

<trackbot> Created ACTION-2861 - Investigate Mozilla hosting an SVG WG F2F in Auckland, NZ in February/March [on Jonathan Watt - due 2010-09-15].

shepazu: obviously there is also SVG Open and TPAC20111
... seems like SVG Open may be in Seattle

ed: what about LGM

ChrisL: it's in Montreal 10-13 May
... AC meeting and possible Interaction Domain meeting 14-17 in Bilbao, Spain

ed: so, if we meet at LGM, it would have to be the first week of May

shepazu: it could just be a short F2F

telcon times

anthony: I'm happy to do 6am australian time

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#Times

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2010&month=4&day=15&hour=20&min=0&sec=0&p1=240&p2=195&p3=43&p4=224&iv=1800

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2010&month=9&day=16&hour=20&min=0&sec=0&p1=240&p2=195&p3=43&p4=224

http://www.timeanddate.com/time/dst2010.html

ed: so, we keep the existing times until October 31
... when DST ends
... FXTF meetings will be on Monday 20:00 UTC for 1 hour

<scribe> ACTION: doug to update FX wiki with telcon times [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action04]

<trackbot> Created ACTION-2862 - Update FX wiki with telcon times [on Doug Schepers - due 2010-09-15].

Non-retain property

ed: this came up at SVG Open

cyril: Andreas Bovens from Opera mentioned the buffered-rendering property, which enables faster rendering after optimization

<cyril> http://www.w3.org/TR/SVGTiny12/painting.html#BufferedRenderingProperty

cyril: for a subtree that's not expected to be dynamic

<cyril> CC: static = "Indicates that the element is not expected to be modified often. "

cyril: I would like to go a step further with a new value that allows you to trash the DOM

anthony: wouldn't that discard the vectors?

cyril: no, you'd keep the internal vector representation, but it would still save memory

anthony: this would be good for the proposed extended path syntax

cyril: we'd have to discuss whether animations or script would still apply

ed: I would like a way to allow a subtree of an SVG that acts as a separate layer, composited on top, which doesn't depend on other parts of the document

shepazu: what about simply allowing SVG in the <image>?

ed: I don't think that gets us the same thing, because there's no interaction

<ed> ... SVGT12 <animation> + buffered-rendering might be a way to go though

<ed> ACTION: cyril to investigate how the buffered-rendering property can be improved for SVG2 [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action05]

<trackbot> Created ACTION-2863 - Investigate how the buffered-rendering property can be improved for SVG2 [on Cyril Concolato - due 2010-09-15].

charter

here's a rough list of stuff in the draft (no order, some duplicates):

* Animation and Media

* Color Management

* Compositing

* Connectors

* Filters

* Integration

* Layout Requirements and Use Cases

* Layout

* Masking and Clipping

* Media Access Events

* Pagination

* Paint Servers

* Parameters

* Transformations

* Vector Effects

* SVG 2

* SVG DOM API

* SVG Fonts

* SVG 2 Requirements

* Scalable Vector Graphics (SVG) Tiny 1.2: Requirements; Specification

* SVG 2 Modular Specification

* SVG Print: Requirements; Part 1: Primer; Part 2: Language

* SVG Filters: Requirements; Part 1: Primer; Part 2: Language

* Paint Servers

* SVG Masking and Clipping

* SVG Vector Effects

* SVG Compositing

* SVG Layout: Requirements; Part 1: Primer; Part 2: Language

* SVG WebFonts

* Media Access Events

<ChrisL> http://ie.microsoft.com/testdrive/Graphics/49ColorProfiles/

ChrisL: we're currently on a charter extension

ed: and will we ask for another one until SVG 1.1 SE is done?

[end break]

ed: I want to see a much better treatment of 'foreignObject', with HTML in particular, including requirements, tight wording, and tests for interoperability

ChrisL: it should say that when the CSS box model is used to render the contents of 'foreignObject', the size of the 'foreignObject' element is taken as the size of the outermost containing block, and starts a new CSS canvas

Resolution: we should prioritize defining 'foreignObject' behavior in SVG Integration

<scribe> ACTION: shepazu to define 'foreignObject' behavior in SVG Integration [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action06]

<trackbot> Created ACTION-2864 - Define 'foreignObject' behavior in SVG Integration [on Doug Schepers - due 2010-09-15].

ed: does this handle zooming and transforms?

CL: I don't think zoom is adequately defined....
... we once had zoom vs. magnify, but we got rid of that

ed: we should say that if you're an HTML+SVG UA, you must support HTML and SVG in the 'foreignObject' element

shepazu: and MathML too

CL: if you support the CSS box model & SVG, then you must support the use of the box model in the SVG 'foreignObject' element

shepazu: I'll add that Transformations may include 2D and 2.5D transforms

Params

shepazu: need to decide on a better syntax that works for CSS as well
... and for a URL syntax that doesn't trigger multiple server requests, and isn't cached, like the "?" delimiter does

CL: what about #params(foo=1,bar=red) ?

shepazu: ok

<scribe> ACTION: shepazu to update Params spec to change URL syntax [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action07]

<trackbot> Created ACTION-2865 - Update Params spec to change URL syntax [on Doug Schepers - due 2010-09-15].

shepazu: that syntax should also work for external CSS stylesheet, if CSS decides to add this too
... I'd like to discuss this with them during the FXTF call

SVG 2

<anthony> CL: What are the hot new features for it?

<anthony> Scribe: anthony

<scribe> ScribeNick: anthony

DS: Tighter with HTML 5

s/Tigher/Tigher integration/

<shepazu> Tighter integration with HTML5 and CSS, including using SVG features like filters and gradients with HTML content

ED: Advanced gradients, transforms, filters
... and compositing

CL: Vector Effects is a fairly visible feature

DS: Params

ED: Params is very useful
... is the feedback I've been getting
... makes things reusable

DS: New gradients (mesh, diffusion curves?)

CL: Was asking at a high level
... looking at blocking out an area as to why you'd use SVG 2 instead of old versions

DS: Component based reuse of SVG is Params
... possibly connectors?

ED: New CSS properties that might apply to SVG
... gives better integration with HTML

DS: Maybe the fact that we are cleaning up some of the cruft and making it more consistent
... and interoperable
... what about canned effects?
... author friendly short hands for common effects

CL: Ease of authoring

DS: Richer SVG and CSS animation
... or maybe cleaner

ED: What features would you be looking for if you were a stand alone UA?
... the shape path thing

DS: Skeleton paths

CC: Wire frames

CL: Vector Effects can draw like a filter and as a stand alone object
... and Super path
... I'd group that with the smooth curves

ED: And the variable stroke width
... all very useful functionality

CL: I'm after a high level summary
... with groupings of these features

AG: Should we make something like that?

CL: Yes
... pulling that stuff together with broad headings would make a nice document

<scribe> ACTION: Chris to Put together a high level overview stating the most important new features in SVG 2 [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action08]

<trackbot> Created ACTION-2866 - Put together a high level overview stating the most important new features in SVG 2 [on Chris Lilley - due 2010-09-15].

CL: This is something I'd expect someone to be able to read in a few minutes
... and have an idea of what we're doing
... Are there any big areas of functionality we've been asked for
... but don't have any work in the area?

DS: Layout and constrains

AG: Have we thought about when we are going to start SVG 2?

DS: I think it is unrealistic for us to simply do it from scratch
... it is not good for us to simply pull things in
... we can bring in sections that we need as place holders
... from 1.1
... and give them a class that gives them a maturity
... that maturity would indicate if it's been reviewed
... there are testable assertions
... that it is consistent with other parts of the spec
... and it has test
... There would be some stylistic thing
... which denotes it's new

CL: I agree we should pull that text in as a place holder

DS: I think if we go for this more rigorous process of review
... we will find inconsistencies that hadn't been found
... or address things that hadn't been addressed
... We talked about having an annotated version of the spec
... and in that version we could have reasons for certain technical decisions

CL: If you do it the other way around
... where you author with the annotations
... and have an XSLT to give you the raw document

DS: My idea was we have a document on the side, in addition to use case and requirements
... which is like a developers guide
... and the annotated version of the spec we'd have links into the developers guide

JW: Some sort of design rational doc sounds reasonable to me
... even for us

DS: Sometimes you're not around CL and it would be good to have that information around
... for discussions
... I'm proposing we have a system

JW: Everyone understands how to add stuff

DS: Right, so people can see why we've made the decision

JW: I think it will save us work explaining why we did something
... rather than trying to recall it

AG: We could link it straight to trackbot

DS: We could put ISSUE numbers in

CL: So when we commit trackbot picks up on it

<shepazu> we could use this: http://www.w3.org/People/Schepers/spec-conventions.html

DS: My proposed stylistic and syntactic convention
... things would be marked up certain way
... and it makes it easy to pull out

ED: I liked the thing that Cameron did
... with the script
... that would link to definitions
... and put them in the spec
... when it was generated

AG: Do we have mark up for assertions?

DS: No, need to add that

<scribe> ACTION: Doug to Add to the common convention document mark up for testable assertions [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action09]

<trackbot> Created ACTION-2867 - Add to the common convention document mark up for testable assertions [on Doug Schepers - due 2010-09-15].

CL: We should have an ID for the assertions

DS: We want to have a link to go to the tests and back

CC: The widget spec being edited while the tests were being edited
... and so what they did was have a hash
... that was generated for each test

DS: To a large degree we can solve that by settling on name conventions
... since we are going to edit the spec by hand
... we can come up meaningful names

CC: I the test suite at the moment we already have names

CL: Sequential number of sections is a bad idea. But sequential number for tests in a section name is ok

DS: How much of Cameron's build system can be used?

ED: I think it's a good idea to use
... it's Java based and uses some XSLT
... and some Perl scripts

CL: If we can modify it to meet our needs
... then that's better than building something from scratch

ED: Already working well with the modules

DS: We can start with that
... and the build system can always be changed

Using href in addition to xlink:href

DS: So the href property would be a getter and setter for the href attribute

CL: And if someone puts in xlink:href what happens?

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href

DS: [Reads out page]

CC: So I have to remember what the value was?
... why being so strict?

ED: That's DOM requirement
... in DOM core

CC: So it's adding a flag probably

DS: That's if only they're using it

CC: maybe that's not an issue because XML events are not being used
... what about the "ev" prefix?

ED: We just use XML events (in SVGT12), and yes you do have to declare the ev prefix to be from XML Events
... you have to define the prefix

DS: Maybe something we need to think about at some point
... we are trying to align with HTML here

Resolution: We accept the proposal on the wiki and we will add this to the integration specification

ED: I think we should probably put this in SVG 2
... it doesn't belong in Integration

DS: Need a new resolution then

Resolution: We accept the proposal for href on the wiki and will add this to the SVG 2 specification

<scribe> ACTION: Doug to Add wiki href proposal to the SVG 2 specification [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action10]

<trackbot> Created ACTION-2868 - Add wiki href proposal to the SVG 2 specification [on Doug Schepers - due 2010-09-15].

Color

CL: There was some good feedback about CieLAB
... it didn't say what the white point was
... to make LAB you find out what the white point
... and you draw a line through the 3D space
... and that becomes the black white line
... we need to specify it so we have a default
... having initially thought that D65 would be the best default
... because that's what SRG be uses
... I'm now convinced that D50 is the one to use

AG: Why?

CL: Because that's what is used when doing the colour conversions
... that's a change I plan to add
... and add some wording to the primer
... It is interesting that IE9 has added colour management

<ed> http://www.w3.org/TR/SVGColor12/

CL: Firefox gets the ICC 4 profiles wrong
... when people buy a printer they use ICC 4 profiles
... and ICC 4 profiles are used for profiling screens
... Apples color sync uses ICC 4 profiles

JW: It badly regressed?
... between 3.0 and 3.11

CL: Yes
... Mozilla said they wanted to have their own library because it was smaller and faster
... but it gives the wrong results
... LCMS 2 does full ICC 2 and 4 support
... and it's faster than LCMS 1
... LCMS 2 was released after Firefox changed away from LCMS 1
... At LGM there was someone from the Ghost script project
... that has added all the colour management stuff that's needed for PDF and Post Script
... He said there was a little module that reads in SVG and converts to PDF
... so if that code was hacked to understand our syntax for LAB and it would go through that library and have PDF
... which has all the colour management syntax
... I believe Inkscape has colour management in the latest version

AG: What about black point?

CL: We could add something about black point compensation
... which says how to join the black up
... means you don't lose shadow detail

AG: Could add it in a later version

CL: That's the update for the module
... I'd like to see it in SVG 2
... One of the conformance class is obeying the profiles in images

ED: Does Firefox do color management for raster images only?

JW: Yes

<scribe> ACTION: Chris to Change the CieLAB with a D50 default white point [recorded in http://www.w3.org/2010/09/08-svg-minutes.html#action11]

<trackbot> Created ACTION-2869 - Change the CieLAB with a D50 default white point [on Chris Lilley - due 2010-09-15].

AG: I have an action which relates to this

ACTION-2606?

<trackbot> ACTION-2606 -- Anthony Grasso to propose wording for "preserve black" attribute for color profiles -- due 2009-06-16 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2606

Meeting ended

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

08 Sep 2010

Attendees

Contents