minutes, 4 November 2011 SVG F2F meeting at TPAC 2011

Hi SVG fans,


please find the minutes from today's F2F meeting at TPAC here:
http://www.w3.org/2011/11/04-svg-minutes.html
and below as text:

- DRAFT -

Friday 4 November 2011 SVG F2F at TPAC2

04 Nov 2011

Agenda

See also: IRC log

Attendees

Present
Jongyoul_Park
Regrets
Chair
Cameron
Scribe
Cyril, Cameron,
Contents

Topics
SVG Japan updates
Mapping Taskforce / Tiling and Layering
testing
svg2 requirements
Hardware acceleration
svg spec editing
requirements once more
path arcto with 360 arcs
polar element
Define <shapePath> element
Component Model
SVG/HTML 5 video tag harmonization
Summary of Action Items
<heycam> ChrisL, I forgot to make minutes, and it looks like the day is already "over" :/
<heycam> ChrisL, (RRSAgent disappeared earlier)
<heycam> oh wrong channel!
<ChrisL> heh
<cyril> scribe: Cyril
<scribe> scribeNick: cyril
SVG Japan updates

CM: First session is Updates from SVG Japan IG and then presentation for a mapping task force
JF: I'd like to share some of the SVG related group in Japan
... the updates of the SVG JIS standardization activity
... JIS has been working for over 3 years
... 3 committees
... the first committee was held in 2009: translation of SVG T 1.2 in Japanese
... the 2010 meeting added features for mapping
... it is called the SVG Tiling module
... KDDI recently the W3C and submitted this spec for consideration by the SVG WG
... this year, we had the 3rd committee and its goal is to finalize the publication of the specs
... both spec should be published as official JIS standards in 2012
... remaining question: is there any room for the alignment for SVG Tiling and Layering module with SVG 2
... the answer is no for the moment
... but we expect to have a chance to update the SVG Tiling and Layering spec when SVG 2.0 will be ready
CM: is there anything specific about Tiny in SVG Tiling and Layer?
JF: there is nothing specific, you can use SVG 1.1
... but the committee requested a scope for SVG Tiling and Layering
... and we chose SVG Tiny 1.2: officially it's a limitation, but technically not
CM: JIS timeline is long, is there any concern about browsers not focusing on Tiny but on Full instead ?
JF: yes, there are some concerns
... but when we decided for SVG T 1.2, the SVG WG was thinking of SVG T 1.2 as the core of future SVG specs
... we can update our standard when SVG 2 becomes available
CM: JIS is 1.2 T + Mapping, that's it
JF: yes
CM: what implementations are you targetting ?
JF: there are several implementations
... of tiling and layering features
... ePub
... ePub 3.0 is being developped
<scribe> ... finished in may
<jun> http://idpf.org/epub3-a-final-recommendation
UNKNOWN_SPEAKER: published as the final specification from IDPF
... ePub 3.0 is based on HTML 5 and CSS technologies, with some support for vertical writing and asian languages
... SVG is also supported
... in the past you could only used SVG referenced from HTML
... in ePub 3 you can have only SVG
... the discussion of the next version has already started
... strong demand to get to high design publications like magazines
... IDPF held a workshop "Advanced Adaptive Layout Workshop"
<jun> http://idpf.org/idpf_workshop_advanced_adaptive_layout
<jun> http://code.google.com/p/epub-revision/wiki/WorkshopOnAdvancedAdaptiveLayout
UNKNOWN_SPEAKER: based on the discussions, IDPF decided to start a new activity Advanced Adaptive Latout WG
<jun> http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter
<jun> http://epub-revision.googlecode.com/svn/trunk/src/proposals/css_page_templates/csspgt-doc.xhtml
UNKNOWN_SPEAKER: starting from 2 Adobe proposals: CSS Regions & Exclusions,
<jun> http://www.adobe.com/devnet/html5/articles/css3-regions.html
UNKNOWN_SPEAKER: and CSS Page Layout
s/PAge Layout/Page Templates/
JD: these specs are new specs and touch layout
... the ePub book has a schedule that is going to be
... because the potential of divergence between CSS and ePub is high
... the proposal that Tab has put recently has more adoption
... but the layout part is still problematic
... the implementers don't have all the answers
CM: the ePub guys want to embed off-the-shelf engines
JD: but the plan also on repurposing the content
JF: IDPF identified similar but different demands from the publishing industries
... like fixed layout
... similar but different from adaptive layout
... there was another workshop last week in Taipei on this topic
... I attended this workshop
<jun> http://idpf.org/news/idpf-workshop-on-fixed-layout-epub-oct-25-2011
CM: I remember something about horizontal page
JF: the discussions are about using combinations of different technologies
... one proposal is based on the use of raster images
... the other proposal uses SVG
CM: is it completely fixed layout
... with no change possible
<jun> http://code.google.com/p/epub-revision/wiki/TaxonomyOfMechanismsForFixedLayout
JF: yes
CL: like a comic book
JF: it seems AAP (Association for American Publishers) and other Japanese publisher for mangas are in favor of this approach
... compared to adaptive layout
... their primary goal is to preserve the author intention
JD: why not PDF then?
<jun> http://code.google.com/p/epub-revision/wiki/TaipeiMeetingNotes
CM: one of the proposed mechanism is PDF
... did they decide ?
JF: no, IDPF decided to have 2 new ad-hoc groups
... rendition mapping data structure
[see Taipei meeting notes for names of groups]
<heycam> Some metadata they seem to want: http://code.google.com/p/epub-revision/wiki/RenditionMetadataAdHocGroup
<jun> http://code.google.com/p/epub-revision/wiki/RenditionMetadataAdHocGroup
<jun> http://code.google.com/p/epub-revision/wiki/RenditionMappingAdHocGroup
JF: in summary, there are 2 activities for high quality
... related but based on different requirements
CM: do they have requirements for SVG ?
JF: not yet
... many japanese publishers creating mangas are interested in using SVG
... for dynamically showing flames with script, even on mobile devices
CM: does ePub 3 target a particular edition of SVG
CL: 1.1 SE
JF: we are interested in keeping working in this area
... Character Information Platform
... a ministry of the Japanese gov released font data
<jun> http://www.meti.go.jp/english/press/2011/1026_02.html
<jun> http://www.meti.go.jp/english/press/2011/0518_02.html
JD: are you involved in that effort
JF: yes, durnig the technical WG within the committee, I'm the chair of the technical WG
<r12a> i guess that METI stands for Ministry of Economy, Trade and Industry
JD: is it the group registering the
<jdaggett_> Hanyo-Denshi
<jun> http://www.ipa.go.jp/about/press/pdf/111026_2press2.pdf
JF: this PDF contains a diagram
JD: in Unicode you have a set of ideographic characters
... but in some cases, there are variants of the same characters
... but it's sometimes hard to say if glyphs are distinct or not
... Unicode code point for a base glyph and then ideographic variations of the character
DS: is it for signatures, names of places
JF: yes
JD: names are not registered, only the characters
DS: like a signature
RI: they can be used for anything
CM: without a register, does it mean that the IVS is not useful
JD: the way Unicode defined it, they have a database (IVD) and interested parties can register this glyphs to have this selector
CL: it's an ongoing registry
JD: but if group A and group B are registering
... there is no requirement to see if the same gkyph is being used
... so you could have 2 ways to encode the same glyph
... it's problematic at a different number of levels
... font designers need to know
... they can't until the parties involved do the effort
... and that hasn't been done
... in June, the CSS WG sent a comment to Unicode, that it is not good for the Web
... because if someone does not have the right font, they wont see the variation
... from the perspective of people concerned about open standards, it's a mess
... in Japan it works but in the long term it's going to be a problem
... especially communicating outside of Japan
JF: METI decided to define the Character Information Platform and created a committee to create a character set
RI: is it defining glyphs and variation ?
JF: yes
... the result is a widely available font
<jun> http://ossipedia.ipa.go.jp/ipamjfont/download.html
JF: the size of the font is 30 MB in OTF
... the number of glyphs is over 58 K
CL: 30 MB is zipped
... and 54 MB otherzise
JF: the name of the font is IPA
Information Technology Promotion Agency
scribe: they provide the list of the characters defined
<jun> http://ossipedia.ipa.go.jp/ipamjfont/mjmojiichiran/
scribe: the table has an image over every glyph provided in SVG format
you can click on each image to get the SVG version
scribe: using the SVG font mechanism
CM: one of the limitation of SVG, is that there wouldnt be ways of defining variations
CL: there would using ligatuers
JD: there is a difference between ligatures and variations
... spacing breaks ligatures
JF: it's a practical way
JD: no it breaks
... OpenType has a mechanism
... that's practical
... it's not gsub but cmap
... base character + selector = glyph
... there are several cases were ligatures are split (letter spacing)
... sometimes ligatures must be turned off
RI: I don't understand the difference between handling lam-alif ligatures and variations
JD: there is a distinction between required ligatures and other ligatures
CL: it would be futile to add i18n features to SVG, it would be huge
DS: and just information about required ligatures only
CL: maybe
DS: I agree that there is an existing mechanism
... but we could find another one
CL: I was pleased to see that the publication provides the font and the mapping
JD: but again the problem is that the publishing industry follows standards by Adobe
... and because of the way this has been registered, there are problems
... we made a comment to Unicode to not have a loose association
JF: another interesting part is the creation of a new technical WG to perform demonstration experiments
... using that font
... I'm the chair of the WG
... with vendors like Microsoft, Mozilla, Google
... on the demonstration system, we are planning to use SVG fonts for non UCS code points
... and we plan to have a WOFF version of the font
... we will probably discuss how we can split the font so that the browsers download only the required glyphs
RI: are you subsetting based on the document used ?
JF: based on unicode-range
RI: you might have then a document using a character that is not in the font
JD: I'm interested in trying to improve the practicality of the subsetting
... you have to put a long list
... but if you group with the most used first and then the least used
... is there a way to decide on names for the ranges
... I've asked Google to try and analyse the number to come with on the Web in Japanese what are the rankings
CL: the meaning of based character + IVS was not defined so these variations won't appear in the ranking
JD: as long as the base character was defined you will get them
CM: for this demonstration, practically, generating a WOFF font might be a good idea
JF: I'd like suggestions from the SVG WG on SVG fonts, how to create WOFF fonts, on the use of SVG in OTF fonts
CL: there are things that OTF does that SVG does not
... and there are things that SVG fonts can do but not OTF
... there is an effort to put SVG outlines in OTF
... that's how we get the best of both worlds
... including multi-colored, animated fonts
... WOFF brings compression, subsetting and license and metadata
JD: the format is not important, but not all browsers support the type 14 of cmap
... not webkit, IE9 does, some version of firefox does
EF: most of this stuff is handled in a platform specific platform not generically in Webkit
JD: for the support in browsers you need to have wide availability of the font and it has to be small size for phones
CM: if you are looking for format, there is not a single one
JF: we already decided on OTF but we want to test other formats
CL: what about Opera and Type 14 cmap ?
ED: I'm not sure
JD: when you subset, instead of have 1 font you have 10
... the first one has the 2K most frequent characters
... in unicode-range, you declare that you don't have the characters outside the range
RI: if you split a 54 MB font in 10, you still have large fonts
<ed> ACTION: ed to check the status of opera support for type 14 CMAP in opentype fonts [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action01]
<trackbot> Created ACTION-3172 - Check the status of opera support for type 14 CMAP in opentype fonts [on Erik Dahlström - due 2011-11-11].
JD: frequency is very important to manage the size
JF: we want to study the feasability of downloadable fonts in Japan
JD: it would be useful to know the frequency of character data
CL: in practice, you want to split the font into 100 of fonts
Mapping Taskforce / Tiling and Layering

ST: I'd like to share some information on the Mapping Taskforce
... Tiling and Layering is a fonctionality for Mapping
<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
ST: I divided in 3 categories
... markup language, fonctionality and UI of the browsers and last API
... some topics were discussed in F2F last week
... I appended my comments to each items
<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Issues_of_SVGTL
<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/SVGTL_Implementations
<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/SVGTL_on_WebKit
CC: why use the <animation> element instead of <use> or <image>?
RESOLUTION: Richard must have a Happy Birthday !
DS: one of the use besides mapping is for High Res photos for medical imaging data
<scribe> ACTION: Doug to contact OpenStreetMap people to participate in the Mapping TF [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action02]
<trackbot> Created ACTION-3173 - Contact OpenStreetMap people to participate in the Mapping TF [on Doug Schepers - due 2011-11-11].
DS: it might make sense to have it as a community group also
[break]
<ed> scribeNick: ed
testing

CL: automated script type testing
<scribe> ... new w3c testing reporting framework, being developed
UNKNOWN_SPEAKER: gets automatic reporting back
CM: different to the test harness thing?
CL: yes
CM: someone should have a look at the existing frameworks to figure out how we can use them
CL: i have some experience with that
<scribe> ACTION: CL to investigate testing template needs for the new test system [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action03]
<trackbot> Created ACTION-3174 - Investigate testing template needs for the new test system [on Chris Lilley - due 2011-11-11].
CL: already discussing how this should work for svg
CC: linking from tests to spec?
CL: yes, you have to edit some metadata to get that, but there's a script that inserts the links to the tests into the spec
CM: when people create tests they should link to the spec
CL: yes, the other way around would be harders
... when we create a setup it will generate a harness automatically
... it gives us pass/fail buttons for manual test reporting
... you can also import results from a textfile
... stats are provided, you can run per chapter, most needed tests (least tested)
CM: what's the current state of running reftests?
CL: not sure about that, need to investigate
CM: what's teh scope of the browser testing group?
CL: infinite, don't know
CM: would be good for automation
... would be good to look into
... svg might need special API's, would be good if someone from here was in that group
... TA you're in that group right?
TA: yes
CM: would be good to sort out testing now so that we can start writing tests while developing the new specs
CL: we will have a good start if we import the existing testsuite
CM: right, but it will still need to go through review again
CL: at 12pm we'll have a guy from nvidia to talk about 2d graphics features
... alex danilo mentioned this new nvidia API at svg open
... we'll hear more about how svg could utilise this
... let's return to the svg2 requirements list
svg2 requirements

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Polar_coordinates_for_paths
CM: polar coordinates for paths
CC: before we dig in, we're still getting requests for features, how should we deal with them?
DS: maybe we should use bugzilla
CC: yes, but is there a cutoff date for new reqs?
DS: we should use bugzilla, one feature per request
... avoid the long lists in one email
... and it gives us trackability
CM: it's unlikely that reqs will come in before we're done going through the list we have atm
... unlikely that we can't handle any additional requests
CC: if we get one or two sure, but if we get a lot of them?
CM: after we've settled on the list of reqs, that's a good cutoff point
... probably ok to keep gathering reqs for a while longer
... ok, back to the issues list
<heycam> http://hoffmann.bplaced.net/svgueb/ppolar.xhtml
CM: this is DOH's proposal
... remember seeing a script impl of his proposal
... not grounded in use-cases
... not sure it's worth the complexity
... it's reasonably simple to do in script
... there's another proposal to be able to setup a polar coordinate system
CC: the whole issue with scripting, there are envs where scripting is not enabled
... need to be sure we don't disregard it if it's an important use-case
... fonts, etc
... not sure if this is the case here
JY: what does it do?
CM: being able to easily create polygons, without having to figure out exact points and so on
... i think this one is probably not so important
... does everyone agree with that?
(silence in the room)
DS: such a small script, we could just add it, but it doesn't seem broadly useful
JY: yes
TA: it does more than just the polygons
DS: i had a competing proposal
... basically a polygon thing, but it wasn't using polar coordinates
... i think it could be useful
... maybe broaden the scope to investigate improving polygon
CM: don't the path extensions already address this?
CC: the script is so small, but we still need to test, which is more work
... even if the implementation is small too
DS: the number of things you can do with it means it needs more testing
TA: if you need total coverage yes
... you can machine generate tests, so it's not impossible
... must be justified by the functionality though
CM: i'd be ok with a req for us to make it easier draw and animate regular polygons
DS: another aspect is that there are visualizations that are polarbased
... would be nice if we could do those easily
CL: if we introduce polar coordinates we'll have to worry about how that works with the existing transforms and so on
... we also have the ref transform, so it can get complex
CM: stars are not regular polygons, but they are similar
CC: you can do them with the polar element
<shepazu> http://svg-whiz.com/svg/StarMaker.svg
CL: in 1996 i was given an action to draft polygon which had number of corners etc, but it was dropped
DS: (shows the starmaker script)
... not a concrete proposal
CM: do we want to broaden the scope outside of regular polygons or not?
... even for regular polygons, you might have a stopsign or something, but how often would it be useful?
DS: stars would be useful, need the centerpoint for easily translation and animation
CM: if the improved path commands would solve the usecase...
CC: right, it's not so important how it's solved at this stage
CM: might open the door for something too complex
RESOLUTION: make it simpler to constuct regular polygons and stars
CM: next, introduce elementbased path syntax
<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Introduce_element-based_path_syntax
DS: have written a prototype, don't know where it is now
... prestty easy to collapse the syntax back to a path
... the EXI group wants the elementbased syntax
... another proposal was to... (doug draws on whiteboard)
<path d="M 0 0..., seg(#somepath) Z"/>
scribe: this would make it possible to do composite paths
... not exactly what the EXI group wanted though
... not clear EXI is the way ppl push content to the web, but we might want to make a module for it
... that might create a division since the content might not work in browsers
... if we do this we need to define a normalization algorithm so that we can go from one to the other syntax
TA: i like it, because generating a path string is a bit annoying
<jun> http://www.svgopen.org/2010/papers/3-Compressing_SVG_with_EXI/
CC: js libraries help you with some of this, have path helpers
... raphael, d3 etc
(DS gives an example of element syntax on whiteboard)
DS: each element has their own attributes
CC: the cubic element could be used for the gradient meshes
... if we can compress svg content to deliver it to mobile phones and networks that's good, but we need to make sure the DOM doesn't explode
CM: it will be slow if the DOM is too big
TA: my use-case is to make a non-sucky path API
CM: it's not clear EXI is the solution
TA: it's for XML, not for html
... unless it's extended
CC: they want a specific coding for elements and attributes for compression
CM: so they can compress based on the schema
TA: don't think svg is a big deal for EXI
JF: EXI can be applied to any xml content
... we are discussing how to apply EXI to html content
DS: it would still have to be wellformed html?
CC: but html is generally small, however svg maps can be huge
JF: maps contain a lot of path data
TA: so we could make an appendix covering this, or a module
DS: yes for transport
CL: a path with an attribute could be expanded out to a shadow dom, lets you fiddle with it
CC: could be done with a nice path API
DS: declarative animation of subpaths
<jun> http://msdn.microsoft.com/en-us/library/cc189041(v=vs.95).aspx
JF: MS silverlight provided two ways to describe the path information
DS: all children of a path could be discarded by the DOM and put into the attribute?
... the DOM doesn't allow that
CM: would feel weird to me
DS: there are modes in the html5 parser where it inserts tbody
... there's precedent for it
CM: i'd be ok with having an appendix for EXI
... but i don't see allowing EXI to compress svg is enough to require implementations to support this syntax
CC: maybe if it got more popular?
CM: would prefer to not resolve to require element syntax, but to have a document for EXI purposes how you could represent paths in element syntax
DS: yoking this to a better path api would be useful
CC: we'd have to make sure the element syntax is better for EXI, there are many ways we could chose the syntax
DS: so we should ask the EXI group about that
... if we do this at all I'd like us to be strict about the normalization
... so that implementations know what to do with this syntax
CM: i would expect browsers to just put it in the DOM and not do anything wiht it
DS: worst of both worlds
<cabanier> Is there a conference code for today's meeting?
CM: if it's alot of overhead to transmit documents like this then we don't want ppl to use this
<scribe> ACTION: JF to talk to the EXI WG about requirements for element based syntax for svg [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action04]
Hardware acceleration

(Neil Travet from nvidia gives presentation about GPU acceleration of svg)
NT: nvidia will get more involved in the svg wg
... we've created an extension to opengl to offload path rendering to the GPU
... up to 100 times faster
... without sacrificing quality, instead improving it
... can save power, good for mobiles
... mixes well with 2d and 3d
... shipping today, all desktop gpus have this in their installed drivers
... coming to mobile soon
... it's a stencil then cover approach
... once the stencil is genrated it can be used for rendering
... has full support for text
... can avoid approximations when running on gpu, improves quality
... more accurate
... doesn't have to do subdivison or tesselation, stroking is exact, caps, dashing supported
... antialiasing uses jitter pattern
... avoids some artefacts, overlaps and holes
... (compares performance software vs hardware)
... hw is often 5 times faster, but it's never slower than software
CC: coat of arms example is slower no?
NT: not slower, it's the same speed
... we have started createing an experimental svg renderer
... missing some parts
... some new features, advanced stroking, sRGB correct rendering
... 4x4 transforms
... mixing text, 3d and paths, proper path perspective transforms
DS: what about filters?
CM: has to work with opengl anyway, so write shaders in GLSL
NT: yes, the css shaders proposal uses that so yes
DS: do you do performance testsuites?
... w3c haven't had any, but we might want to consider performance a test criteria
NT: we have that discussion in the khronos group
... but who are we to judge the use-cases, depends on other requirements, not the same for everyone
DS: sure, but just being able to test things that are meant to be performant
NT: but you'd have to be careful to not construct a benchmark
<stakagi> About projective transforms, Is Mercator Projection possible?
NT: not sure
CM: one of the things that come up when discussing features is whether things are easily hw acc
... so what's possible to do in graphics libs
... would be good to know if design decisions we do would make things better or worse for hw acc
... also whether it willl take time before drivers support these things
NT: i'm pushing nvidia to join svg wg
... to have better communcations with the group
DS: is intel a member of khronos?
NT: yes
DS: we could consider making a joint deliverable between khronos and w3c
NT: the value of khronos is that all the hw vendors are there
EF: what do the other vendors think of the nvidia path extension proposal?
NT: it's a little bit soon for mobile
... but it's desktop today
EF: for the vendors that have the capability do they support hte proposal?
NT: we haven't officially proposed it yet, we're waiting for feedback
EM: motorola mobility is really interested in this
CM: can direct2d do similar things?
<cabanier> Reading your documentation, there is a novel way of doing anti-aliasing that doesn't require FSAA. Can you tell us how it's done? Is there a test application that demoes it?
JY: i don't know the details, but fir filter effects yes
NT: the test app uses AA in the gpu
... 16 bits of stochastic AA
RC: the AA implementation looks interesting, seems to require less memory
CM: we discussed seams in svg rendering the other day, and the person asked for FSAA to be added
... are there other good approaches we should consider?
NT: reached the end of my expertise, sorry
DS: having you help us with testing and creating tests, and reusing our tests
... would be good
NT: yes, we could help out with that
DS: mutually beneficial spiral yes, for hw vendors too
NT: it's a bit different from direct2d, but it's not a layer on top of gl, it's an extension, to access the gpu directly
CM: would be great to have mark join the group
DS: would be good to get some hw people on the wg
--- break for lunch ---
resumes at 2pm
<Tavmjong> http://tavmjong.free.fr/SVG/SPEC/Spec.html
<ChrisL> scribenick: ChrisL
svg spec editing

<Tavmjong> http://tavmjong.free.fr/SVG/SPEC/Spec.html
tb: spent some time working on this document, wrote upmy experiences
... goal A clearly written SVG 2.0 specification that also happens to look good.
... css3 fons spec used as a model
... changed stylesheet, used css3 values style
... added an annotation class
... preserves history of the reason for decisions
cm: switched off by default and alternate stylesheet to show?
tb: yes
... added some svg-specific styling also
... publish.xml changed, replaced tables with divs which style easier. updated figure handling to allow captions
cm: looks a lot more like the css fonts figures
tb: current spec lacks a lot of figures
... unified style, some graphics were tiny others huge, and the colours all over the place
... for svg graphics, updated to remove dtd and change titles to be useful
... attr lists are all crammed together, replaced by paragraphs
... rather than line breaks
... much more readable
cm: never liked the old styling anyway
<cyril> http://dev.w3.org/csswg/css3-transforms/
cm: vincent has also experimented with specs, see his css transforms spec as an example
... started from same stylesheet, made more changes
... we need to discuss together and settle on a consistent spec style
cc: so you changed to a less obvious gradient, light purple to white rather than red to green
... previously you could see the exact stops
... not against making colours less jarring but you should still see the differences between the colours
cm: do like the additionalfigues, they explain it well
ed: better if h & v lines aligned with pixel grid so they are sharp
cl: i think they are just grey lines, not intended to be black
cm: what about including inline figures
tb: some will not render correctly in browsers, if they use new features
cm: the circlesexampleis like the nvidia demo earlier today, bunched up radial gradients
cl: well known case that depends on sub-pixel precision
tb: I added solid solid color
cm: we resolved to add that?
(several: yes)
cc: its below where we got to in requirements list
tb: is there a list?
cm: added to the wiki page, it links to the minutes
... probably not what you want to link to from the spec annotation though
tb: what would be better
cc: its nice
cm: extra figures are great, colours can be discussed
... general direction of spacing etc is good
... may need some more radical restructuring. in terms of dom rather than how markup is rendered
... ut that does not present the current improvements
cc: dom interfaces remain in the chapter?
cm: yes and should be more prominent in each section
... so tav keep on experimenting, this is helpful
ed: so we are going with the testing framework, might be nice to annotate things to keep them separate for the spec
... maintained by bugzilla and then imported in
... concern on the annotations getting out of date
cm: like the annotations that say what is new
... see issue 4 in linear gradients
"Could this be written in a less legalese way? "
cc: lacuna value was used to express that in tiny1.2
cl: yes and I see erik suggested adopting that in 2 - I agree
cc: we need a ara upfront in the spec explaining lacuna, default, inititial etc
<cyril> s/a ara/a paragraph/
cl: we need to be precise, don't want to be short and imprecise
cm: great work tav
cc: you have not put this in mercurial?
tb: no, not yet and not sure how to
cm: jwatt wrpte it up in a wiki page
<cyril> s/wrpte/wrote/
s/wrpte/wrote/
ds: talking with vincent about this restyling?
cm: yes he is, we mentioned that earlier
ds: should have a single style
cl: yes the point was made earlier
cc: intereting the two editing companies are providing styles (adobe and inkscape)
ds: like the annoations
tb: by default the style for those is turned off
ds: any spec freature we put in the spec should have ids so they can be linked to
s/freature/feature/
cm: chris was saying earlier about generating links to tests
cl: sync issue with maintaining info in multiple places
ds: scheme css wg is usig is not fine grained enough. spec section is good but specific assertions is much better
cl: in woff the first link is to section and subsequent ones to specific testable assertions
cc: so where are the rules for editing?
ds: wiki page
... and we should work on this with other groups as well
cl: we need to document the existing spec first
ds: yes, but we have traction in several groups already, especially for apis and events - things we all want to mark up
cl: the text "issue 6" etc is css text so its not searchable or copy/pastable
ds: they should link to actual isues in tracker
cm: and when you delete one the others would renumber
s/isues/issues/
tb: some of those issues would not be in tracker
cl: prefer they are all in tracker
ds: for anything like that, it needs to link to a bug tracker
cm: to capture some initial rules, could you start a wiki page that lists these?
cl: and cameron please document or link to the xml build system docs
<heycam> ACTION: Tav to write up wiki page documenting spec writing rules, like annotations [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action05]
<trackbot> Created ACTION-3176 - Write up wiki page documenting spec writing rules, like annotations [on Tavmjong Bah - due 2011-11-11].
cm: good to have a go at incorporating this into the repository and try to build it
action; cameron to ensure current markup rules linked from tav's wiki page on editing
<scribe> ACTION: cameron to ensure current markup rules linked from tav's wiki page on editing [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action06]
<trackbot> Created ACTION-3177 - Ensure current markup rules linked from tav's wiki page on editing [on Cameron McCormack - due 2011-11-11].
cm: in 15 minutes we have web components work discussion, starts at 3pm. so before, we could look at one or two requireents issues
requirements once more

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Look_at_making_path_arcto_command_work_with_drawing_360_degree_arcs
path arcto with 360 arcs

ed: might fall out of the pattern elements we discussed previously
cm: maybe turtle graphics help here
... good to accept this requirement
ed: express as making it possible to make a complete circle on a path
cm: boraoded to makeing arcs easier
cl: (explains history of current arc command)
cm: broadened to makeing arcs easier
jf: can confirm hosting of SVG in Australia
cm: turtle graphics will break the "command generates new current point" paradigm
cl: don't like that
resolution: make arcs in paths easier
polar element

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Polar_element
cm: this is the fancy flowers one, previous one was polar coords inside a path
... this is an element that makes stars, etc
tb: inkscape has these sort of shapes
... good to include these
ds: but it can't animate them live in the browser
tb; also, native support would make our generated files smaller
<heycam> http://hoffmann.bplaced.net/svgueb/polar.php
cm: so, we resolved not to include this one in svg2 ....
... because although it can make some nice artistic effects the added complexity is rather specific and not so useful in the general case
resolved: wil not add a polar element in svg2
Define <shapePath> element

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Define_.3CshapePath.3E_element
cl: this is positioning along a path, not warping along a path which we already rejected
ds: textPath lets to place a list of shapes along a path, as long as they are glyphs
... this is the same except not glyphs.
... not thought much about spacing and sizing issues
<Tavmjong> Just got kicked off conference call... hour is up.
ds: this is a way of doing certain marker-like efects that markers can't do
<cyril> http://gpac.sourceforge.net/screenshots/pathlayout.jpg
(discussion of text along a path)
cc: gpac has this, text and shapes mixed along a path
ed: at opera we had a way to put graphics inside an anchor tag
<Tavmjong> yes
ds: if we have textPath and shapePath these could take references to other eleents, rendered in order. could be text or shapes
<Tavmjong> http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-GenerateFromPath.html#Extensions-PatternAlongPath
cc: need an anchor point per shape
cl: like baseline for glyphs
<ed> se/at opera we had a way to put graphics inside an anchor tag/IIRC opera at one point in time allowed shapes inside of anchor tags as part of a textPath, because the DTD allows pretty much anything inside <a>/
cc: width of the object is the advance for the next object
... boundingbox most likely
rossen: its straightforward for some shapes, not clear for arbitrary shapes
cc: anythink like this in css?
rossen; no , was thinking of implementing textPath in IE
ds: (draws on board) path to align to, and child elements which are use or path, these have an x and to alighn them, and an orient to say which way up
... autorotate or not
cc: like animateMotion
ds; yes
tb: Copies of the single yellow star are placed along a path. The star is deformed to follow the path.
ds: can repeat these things
... repeat n times or repeat to follow whole path
... can do custom dash patterns like this
cc: already possible to hack this, so a clear way forward would not have too much implementation cost. what are the use cases?
cm: markers not at endpoints
ds: railway tracks, custom pattersn eg for mapping
cl: electrical diagrams
ds; we brainstormed this at svg f2f a couple years ago but we were hung up on other work
scribe: markers are not clickable, want these to be clickable
... click would say how far along the path and what the original object was and the repeat count
ds: putting text along this as well, like text on roads
cl: repeat groups
ds: scaling and non scaling
cm: want to resolve onuc&r not on syntax
cc: placing object on a path, mixing text and objects, and repeating. these are three separate things
cm: these are a bit like the deforming objects on a path
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
s/onuc/on uc/
RESOLUTION: We will allow objects to be positioned along a path
cm: basically, this would be improved positioning of markers
... being able to place a diamond every 10 units along a path, for example
cc: similarities between markers and dashes
-- 10 minute break --
Component Model

DS: SVG has the 'use' element
... which has a concept of a shadow tree
... since it was an early idea, there were various problems with it
... problems with the DOM interface, underlying architecture, performance
... what we'd like to do is to rip at those parts of SVG that have some concept of reusability, and replace them with the Component Model
TA: there are some fundamental parts of use that can be represented by Component Model semantics
... 'use' points at a template, and is rendered as the same way as you transplanted that template whereever the 'use' is
... shadow dom works the same way
... more specifically, 'use' doesn't actually have children, the shadow tree isn't really in the dom
... 'use' is supposed to be fast when spamming it in the dom
... that's not the case in implementations
... but we want it to be fast, and we want to satisify this case with shadow dom too
... we want to allow a "projected shadow"
... the template defines the "one and only" copy of the dom
... all the instances just pull a render tree from that
... they lay out as if it's there, but all dom/styling information comes from the one instance in the template
DG: all browsers are optimized to create and throw away render boxes
... dom, not so much
... the idea is that projected trees have one dom but can be rendered in multiple places
DS: can you change things?
TA: if you change it, it changes for everything
DG: with projected dom, there is no instance
TA: in svg, you can't tweak the instance dom either
... there's an instance tree, but you can only style the instance via inheritance from the 'use'
... all selector matching is done on the template itlsef
s/itlsef/itself/
scribe: this is the only complicated thing
... the styling part we want to figure out
... what amount of styling per instance is required, how we can do this in a sane manner
JY: I don't think our implementation is completely crazy as cloning everything, but not sure
DS: [ draws an example ]
[ people wanting to change little parts of a 'use'd tree, not just with simple inheritance overriding ]
TA: if we go with the simple, cheap, projected tree, where everyone gets their own render tree
... there's no styling allowed from the 'use' instance
... that's less than ideal
... how can we do this in a saner manner?
... doing inheritance from the 'use' is rather bad, since that works over the dom tree, not the render tree
... "pretending" you have a dom there, even if there isn't
... the situation for markers can be a bit saner
... you can specify currentFill and currentStroke on dom nodes in the template, but they resolve differently depending on the instance
... if that's not insane, i want to see whether we can apply this to component model
CM: people haven't implemented currentFill/currentStroke property values yet
CC: one problem I found with 'use', you have to pass the whole inherited properties in
... I would rather have an explicit list of properties that you pass through
TA: don't allow the full set of properties
CC: or you use something we you can by default put all properties to initial value
TA: are used values resolved still with dom tree information? or is it a render tree thing?
DG: in webkit, it's when we're doing layout
... the key problem with the projected dom, you'll have multiple render trees, one dom, no way for them to resolve differently
TA: used values have to resolve differently
... if you said width:50% in a template, and project it out, you wouldn't be able to resolve that until you laid out the instance
... if that works, we could specify a syntax for "used value" variables
... and let that pass data into the instances
CM: won't resolving 50% later mean you get wildly different boxes?
TA: not necessarily, used values are handled after layout
ED: what about a 'use' of a 'use'?
TA: that just falls out of the shadow dom model
ED: the other tricky thing is using an external document
TA: didn't know you could do that
s/using an/using elements from an/
DG: every rendering of the shadow tree, for a "normal" shadow tree, is backed by real dom nodes
... so that's cloning a dom subtree
... projected trees operate in a way where you have a template that has a picture of the dom, but the rendering is projected to different places in the tree
DS: could there be the idea of a projected tree with decoration?
TA: if we define a form of variables that only resolve at "used value" time, that will work
DS: I'd like to be able to get at the computed values in the projection
... another aspect of all of this is, a 'use' instance ... is this a rendering tree?
... if my reference thing is so big, and the instance is bigger...
TA: this is not rendering into a bitmap
... so it's before rasterisation
DS: I understand what you're trying to avoid, but if you had some little decorations on this, which were the "diff" of the dom, ...
TA: we should be able to do this use case, different colours
DS: i'd be worried about authors accidentally incurring performance penalty
TA: we shouldn't do the conversion from projected to real shadow implicitly
DG: do we really want a projected tree?
TA: I think we do want to be able to spam a lot of a single template without a big performance impact
JS: i'm not a layout expert, but I know that we have a pointer from all frames to their content node
... which we use a lot
... that breaks down in this case
... you can't point to the content node and say that's the thing it's resolving style against
... I agree we need this, it will be complicated to implement
... I think you'd want to copy it for now, to get the behaviour, but then do enough decently sized changes to allow not copying
DG: webkit has the same problem
TA: the SVG layout model is much simpler, the only thing you need to know from the outside world is what the coordinate system is
CM: for %age resolution?
TA: yes, and general sizing of user coordinates
... html is a lot more complex
... we could make these projection trees replaced elements, so they have a definite width/height
... they participate in outer pages layout, as opaque boxes, then figure out the size of the bounds, lay out the internals
<JanL> when does the next discussion on svg/html5 <video> start?
very soon :)
<JanL> thanx
<JanL> just checking
JS: the hardest thing is the crazy svg thing, inheritance from two situations
<dglazkov> we win!
<cyril> scribe:
<cyril> scribe: Cyril
<scribe> scribeNick: Cyril
SVG/HTML 5 video tag harmonization

JL: I'm with Ericsson, coming from the Web & TV IG
... on how the tv industry can influence W3C
... the question came up of how the SVG and HTML 5 video tag will merge
... I want to put the discussion on the floor
... the observation from the IG is that there would a lot of synergies if you could use the HTML 5 video tag in SVG
GP: or if we had a functionaly equivalent tag in SVG
JL: there's a lot of control in the HTML 5 video tag
... tracks, etc.
... being able to reuse that in SVG would be interesting
CC: is there a document/analysis of the difference ?
JL: I come the OpenIPTV forum and we identified several gaps, but HTML 5 has evolved since then
... all the bugs are almost fixed
GP: at this stage, there was no analysis made
... but is it the goal to merge in the long term ?
CS: my understanding is that the video tag in SVG and in HTML they don't use the same code base
... is there a fondamental reason why they wouldn't use the same code
ED: SVG does not use the CSS Box model
... the underlying code is already shared
<ed> s/underlying code is already shared/underlying code (for loading and decoding video, putting it somewhere) is already mostly shared/
CC: in general the goal of the SVG WG is to align with HTML as much as possible
... having the same model, even if the syntax differ
JL: what is the next step ?
... do we need proposals
DS: the SVG video element only exists in SVG Tiny 1.2
... SVG 2.0 is not necessarily import all features from SVG Tiny 1.2
... there is no consensus in the group that all features of SVG T 1.2 are relevant in the HTML 5 world
... I believe it would be ideal if we had a video element that would be a super set of the HTML 5 video
<ed> s/CSS Box model/CSS Box model for laying out svg elements/
DS: SVG Tiny 1.2 comes from SMIL and they are not in HTML 5 video
... the quwstion is are those desirable ?
... but I heard concerns that the animations and the video properties are not in the same stack
JL: often the video layer is done in hardware
... the question is should there be restriction on the way it can be manipulated
EF: speaking as an implementer, some of the things specified in HTML 5 is not implementable
... like a CSS Shader on a video on a mobile
... like multiple videos
DS: I dont think it's profitable to us to define a profile for mobiles when only hints are sufficient
... because the standards pace and the silicon pace are not the same
... but point taken
EF: simple cases of manipulation on desktop work but complex cases might not work
ED: I'm not sure it's possible to do the same
... for instance, the transformBehavior attribute is not in HTML 5
... I don't know if it's easy to have the HTML 5 video in SVG
DS: the fondamental question is the SMIL thing
CC: this is not a problem
... people are just scared of SMIL
... but the SMIL timing module when considering a single time container is very simple
GP: some the visual parts are not implementable on STB
... but people want would like multiple video tracks
... but people want would like multiple subtitle tracks
[JanL showing the comparison table from OIPF]
JL: we are mostly interested on video control use cases
<JanL> http://www.oipf.tv/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf
CS: there are 2 issues: what are the different subsets/intersection of features; should that be directly addressed to reach a common understanding
<JanL> annex L, page 360
CS: if we agree on the second question, we can then work on the other question
GP: is there a market for SVG video
<JanL> this includes a table comparing SVG Tiny video element with OIPF embedded video objects defined in the spec
DS: we could have an SVG element behaving the same as the HTML 5 video element
TA: the video element of HTML 5 in the SVG namespace
JL: this sounds like a good idea
DS: we talked about HTML and SVG more tightly coupled in terms of parsing
... when parsing HTML + SVG, when the video element is encountered, what would be the namespace of the video element
... Is there any objection to having a video element in SVG namespace with the same characteristics as the video element ?
... would it be identical or a super set ?
... if we extend it, I would like to have them also applicable in HTML
TA: we should be working toward a world where the SVG and HTML are the same language
RESOLUTION: SVG 2 will have a video element in SVG namespace with the same characteristics as the HTML 5 video element
... SVG 2 will have an audio element in SVG namespace with the same characteristics as the HTML 5 audio element
... this includes the track, audio api, blah blah blah
<stakagi> controls property?
ED: the UI controls might be different
DS: I would expect them to be the same
... you can always make your own SVG controls if you wish
EF: what would be the difference in using a foreignObject element ?
DS: you incur some performance problems with fO video that you would not have with native video
JY: we don't implement fO in IE
ED: the problems are at least in Opera
JL: how soon would this introduction take place
DS: 6 months maybe
<scribe> ACTION: Doug to add HTML video/audio elements to SVG 2 [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action07]
<trackbot> Created ACTION-3178 - Add HTML video/audio elements to SVG 2 [on Doug Schepers - due 2011-11-11].
DS: we could have an audio/video module that extends SVG 1.1
JL: that would be better in the timing perspective
... that would make a difference
DS: we could have a spec in LC by Q1 2012
RESOLUTION: We will have a module to SVG 1.1 to add audio/video elements with parity to HTML 5, given resources
<shepazu> trackbot, end telcon
Summary of Action Items

[NEW] ACTION: cameron to ensure current markup rules linked from tav's wiki page on editing [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action06]
[NEW] ACTION: CL to investigate testing template needs for the new test system [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action03]
[NEW] ACTION: Doug to add HTML video/audio elements to SVG 2 [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action07]
[NEW] ACTION: Doug to contact OpenStreetMap people to participate in the Mapping TF [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action02]
[NEW] ACTION: ed to check the status of opera support for type 14 CMAP in opentype fonts [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action01]
[NEW] ACTION: JF to talk to the EXI WG about requirements for element based syntax for svg [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action04]
[NEW] ACTION: Tav to write up wiki page documenting spec writing rules, like annotations [recorded in http://www.w3.org/2011/11/04-svg-minutes.html#action05]
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/11/04 23:55:35 $
Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/anszer/answer/
FAILED: s/PAge Layout/Page Templates/
Succeeded: s/a new ad-hoc group/2 new ad-hoc groups/
Succeeded: s/signatures/signature/
Succeeded: s/of/off/
Succeeded: s/tests into/links to the tests into/
Succeeded: s/let's/lets/
Succeeded: s/testing and creating tests/testing and creating tests, and reusing our tests/
FAILED: s/a ara/a paragraph/
FAILED: s/wrpte/wrote/
FAILED: s/wrpte/wrote/
Succeeded: s/ret/rest/
FAILED: s/freature/feature/
FAILED: s/isues/issues/
Succeeded: s/wil/will/
FAILED: s/onuc/on uc/
FAILED: s/itlsef/itself/
FAILED: s/using an/using elements from an/
FAILED: s/underlying code is already shared/underlying code (for loading and decoding video, putting it somewhere) is already mostly shared/
FAILED: s/CSS Box model/CSS Box model for laying out svg elements/
Succeeded: s/track/track, source/
Found Scribe: Cyril
Inferring ScribeNick: cyril
Found ScribeNick: cyril
Found ScribeNick: ed
Found ScribeNick: ChrisL
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe:
Found Scribe: Cyril
Inferring ScribeNick: cyril
Found ScribeNick: Cyril
Scribes: Cyril, Cameron,
ScribeNicks: cyril, ed, ChrisL, heycam
Present: Jongyoul_Park

WARNING: Fewer than 3 people found for Present list!

Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
Got date from IRC log name: 04 Nov 2011
Guessing minutes URL: http://www.w3.org/2011/11/04-svg-minutes.html
People with action items: cameron cl doug ed jf tav

[End of scribe.perl diagnostic output]

Cyril
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.