Friday 4 November 2011 SVG F2F at TPAC2 -- 04 Nov 2011

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

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

- DRAFT -

Friday 4 November 2011 SVG F2F at TPAC2

04 Nov 2011

Attendees

Contents

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

Scribe.perl diagnostic output