IRC log of svg on 2011-11-04

Timestamps are in UTC.

00:19:30 [RRSAgent]
RRSAgent has joined #svg
00:19:30 [RRSAgent]
logging to
00:19:44 [ChrisL]
ChrisL has joined #svg
00:20:11 [heycam]
ChrisL, I forgot to make minutes, and it looks like the day is already "over" :/
00:20:20 [heycam]
ChrisL, (RRSAgent disappeared earlier)
00:21:19 [ChrisL]
rrsagent, make minutes
00:21:19 [RRSAgent]
I have made the request to generate ChrisL
00:21:26 [heycam]
oh wrong channel!
00:21:34 [ChrisL]
01:02:47 [myakura]
myakura has joined #svg
01:30:51 [dino]
dino has joined #svg
01:34:14 [myakura]
myakura has joined #svg
01:55:25 [stakagi]
stakagi has joined #svg
02:41:59 [si-wei]
si-wei has joined #svg
02:43:04 [thorton]
thorton has joined #svg
02:43:24 [si-wei_]
si-wei_ has joined #svg
03:07:40 [myakura]
myakura has joined #svg
03:28:18 [myakura]
myakura has joined #svg
04:22:39 [plinss]
plinss has joined #svg
15:53:44 [RRSAgent]
RRSAgent has joined #svg
15:53:44 [RRSAgent]
logging to
15:53:48 [Zakim]
Zakim has joined #svg
15:53:50 [jun]
jun has joined #svg
15:53:56 [heycam]
RRSAgent, this meeting spans midnight
15:54:23 [plinss]
plinss has joined #svg
15:54:26 [heycam]
Meeting: Friday 4 November 2011 SVG F2F at TPAC2
15:54:29 [heycam]
Chair: Cameron
15:54:34 [heycam]
15:58:32 [stakagi]
stakagi has joined #svg
15:58:56 [si-wei]
si-wei has joined #svg
16:01:26 [cyril]
cyril has joined #svg
16:02:19 [cyril]
scribe: Cyril
16:02:24 [cyril]
scribeNick: cyril
16:02:36 [cyril]
Topic: SVG Japan updates
16:03:19 [thorton]
thorton has joined #svg
16:03:41 [thorton]
thorton has joined #svg
16:04:37 [Rossen]
Rossen has joined #svg
16:05:35 [cyril]
CM: First session is Updates from SVG Japan IG and then presentation for a mapping task force
16:05:47 [cyril]
JF: I'd like to share some of the SVG related group in Japan
16:06:01 [cyril]
... the updates of the SVG JIS standardization activity
16:06:11 [cyril]
... JIS has been working for over 3 years
16:06:12 [jdaggett_]
jdaggett_ has joined #svg
16:06:15 [cyril]
... 3 committees
16:06:24 [howard]
howard has joined #svg
16:06:39 [cyril]
... the first committee was held in 2009: translation of SVG T 1.2 in Japanese
16:06:49 [cyril]
... the 2010 meeting added features for mapping
16:07:00 [cyril]
... it is called the SVG Tiling module
16:07:29 [cyril]
... KDDI recently the W3C and submitted this spec for consideration by the SVG WG
16:07:49 [cyril]
... this year, we had the 3rd committee and its goal is to finalize the publication of the specs
16:08:12 [cyril]
... both spec should be published as official JIS standards in 2012
16:08:15 [si-wei]
si-wei has joined #svg
16:08:23 [efidler]
efidler has joined #svg
16:08:33 [cyril]
... remaining question: is there any room for the alignment for SVG Tiling and Layering module with SVG 2
16:08:41 [cyril]
... the anszer is no for the moment
16:09:02 [cyril]
... but we expect to have a chance to update the SVG Tiling and Layering spec when SVG 2.0 will be ready
16:09:08 [r12a]
r12a has joined #svg
16:09:13 [cyril]
16:09:29 [cyril]
CM: is there anything specific about Tiny in SVG Tiling and Layer?
16:09:39 [cyril]
JF: there is nothing specific, you can use SVG 1.1
16:09:54 [cyril]
... but the committee requested a scope for SVG Tiling and Layering
16:10:18 [cyril]
... and we chose SVG Tiny 1.2: officially it's a limitation, but technically not
16:10:46 [cyril]
CM: JIS timeline is long, is there any concern about browsers not focusing on Tiny but on Full instead ?
16:10:53 [cyril]
JF: yes, there are some concerns
16:11:22 [cyril]
... 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
16:11:39 [cyril]
... we can update our standard when SVG 2 becomes available
16:11:57 [cyril]
CM: JIS is 1.2 T + Mapping, that's it
16:11:59 [cyril]
JF: yes
16:12:21 [cyril]
CM: what implementations are you targetting ?
16:12:32 [cyril]
JF: there are several implementations
16:12:38 [cyril]
... of tiling and layering features
16:13:12 [cyril]
JF: ePub
16:13:23 [cyril]
... ePub 3.0 is being developped
16:13:30 [cyril]
... finished in may
16:13:39 [jun]
16:13:41 [cyril]
... published as the final specification from IDPF
16:14:13 [cyril]
... ePub 3.0 is based on HTML 5 and CSS technologies, with some support for vertical writing and asian languages
16:14:21 [cyril]
... SVG is also supported
16:14:31 [cyril]
... in the past you could only used SVG referenced from HTML
16:14:41 [TabAtkins_]
TabAtkins_ has joined #svg
16:14:48 [cyril]
... in ePub 3 you can have only SVG
16:15:15 [cyril]
... the discussion of the next version has already started
16:15:22 [cyril]
... strong demand to get to high design publications like magazines
16:15:39 [cyril]
... IDPF held a workshop "Advanced Adaptive Layout Workshop"
16:15:42 [jun]
16:15:53 [jun]
16:16:30 [cyril]
... based on the discussions, IDPF decided to start a new activity Advanced Adaptive Latout WG
16:16:54 [jun]
16:17:11 [jun]
16:17:12 [cyril]
... starting from 2 Adobe proposals: CSS Regions & Exclusions,
16:17:13 [jen]
jen has joined #svg
16:17:25 [jun]
16:17:38 [cyril]
... and CSS Page Layout
16:17:50 [cyril]
s/PAge Layout/Page Templates/
16:18:00 [cyril]
JD: these specs are new specs and touch layout
16:18:18 [cyril]
... the ePub book has a schedule that is going to be
16:18:32 [cyril]
... because the potential of divergence between CSS and ePub is high
16:19:00 [cyril]
... the proposal that Tab has put recently has more adoption
16:19:13 [cyril]
... but the layout part is still problematic
16:19:29 [cyril]
... the implementers don't have all the answers
16:19:45 [cyril]
CM: the ePub guys want to embed off-the-shelf engines
16:19:57 [cyril]
JD: but the plan also on repurposing the content
16:20:19 [cyril]
JF: IDPF identified similar but different demands from the publishing industries
16:20:24 [cyril]
... like fixed layout
16:20:33 [cyril]
... similar but different from adaptive layout
16:20:51 [cyril]
... there was another workshop last week in Taipei on this topic
16:20:57 [cyril]
... I attended this workshop
16:21:01 [jun]
16:21:16 [cyril]
CM: I remember something about horizontal page
16:21:20 [ericm]
ericm has joined #svg
16:21:41 [cyril]
JF: the discussions are about using combinations of different technologies
16:21:52 [cyril]
... one proposal is based on the use of raster images
16:22:00 [cyril]
... the other proposal uses SVG
16:22:11 [cyril]
CM: is it completely fixed layout
16:22:15 [cyril]
... with no change possible
16:22:17 [jun]
16:22:18 [cyril]
JF: yes
16:22:24 [cyril]
CL: like a comic book
16:23:00 [cyril]
JF: it seems AAP (Association for American Publishers) and other Japanese publisher for mangas are in favor of this approach
16:23:13 [cyril]
... compared to adaptive layout
16:23:24 [cyril]
... their primary goal is to preserve the author intention
16:23:41 [cyril]
JD: why not PDF then?
16:24:12 [jun]
16:24:13 [cyril]
CM: one of the proposed mechanism is PDF
16:24:15 [cyril]
... did they decide ?
16:24:31 [cyril]
JF: no, IDPF decided to have a new ad-hoc group
16:24:42 [cyril]
... rendition mapping data structure
16:25:02 [cyril]
[see Taipei meeting notes for names of groups]
16:25:13 [heycam]
Some metadata they seem to want:
16:25:17 [jun]
16:25:17 [jun]
16:25:23 [karl]
karl has joined #svg
16:25:29 [cyril]
s/a new ad-hoc group/2 new ad-hoc groups/
16:25:57 [cyril]
JF: in summary, there are 2 activities for high quality
16:26:11 [cyril]
... related but based on different requirements
16:26:21 [cyril]
CM: do they have requirements for SVG ?
16:26:25 [cyril]
JF: not yet
16:26:55 [shepazu]
shepazu has joined #svg
16:26:56 [cyril]
... many japanese publishers creating mangas are interested in using SVG
16:27:15 [cyril]
... for dynamically showing flames with script, even on mobile devices
16:27:28 [cyril]
CM: does ePub 3 target a particular edition of SVG
16:27:31 [cyril]
CL: 1.1 SE
16:28:02 [cyril]
JF: we are interested in keeping working in this area
16:28:18 [cyril]
JF: Character Information Platform
16:28:40 [cyril]
... a ministry of the Japanese gov released font data
16:28:42 [jun]
16:28:49 [jun]
16:29:12 [cyril]
JD: are you involved in that effort
16:29:41 [cyril]
JF: yes, durnig the technical WG within the committee, I'm the chair of the technical WG
16:29:59 [r12a]
i guess that METI stands for Ministry of Economy, Trade and Industry
16:30:00 [cyril]
JD: is it the group registering the
16:30:14 [jdaggett_]
16:30:25 [jun]
16:31:17 [cyril]
JF: this PDF contains a diagram
16:31:32 [cyril]
JD: in Unicode you have a set of ideographic characters
16:31:47 [cyril]
... but in some cases, there are variants of the same characters
16:32:11 [cyril]
... but it's sometimes hard to say if glyphs are distinct or not
16:32:32 [cyril]
... Unicode code point for a base glyph and then ideographic variations of the character
16:32:45 [cyril]
DS: is it for signatures, names of places
16:32:47 [cyril]
JF: yes
16:33:17 [cyril]
JD: names are not registered, only the characters
16:33:24 [cyril]
DS: like a signatures
16:33:31 [cyril]
16:33:38 [cyril]
RI: they can be used for anything
16:34:01 [cyril]
CM: without a register, does it mean that the IVS is not useful
16:34:48 [cyril]
JD: the way Unicode defined it, they have a database (IVD) and interested parties can register this glyphs to have this selector
16:34:56 [cyril]
CL: it's an ongoing registry
16:35:11 [cyril]
JD: but if group A and group B are registering
16:35:19 [cyril]
... there is no requirement to see if the same gkyph is being used
16:35:31 [cyril]
... so you could have 2 ways to encode the same glyph
16:35:44 [cyril]
... it's problematic at a different number of levels
16:35:55 [cyril]
... font designers need to know
16:36:13 [cyril]
... they can't until the parties involved do the effort
16:36:16 [cyril]
... and that hasn't been done
16:36:32 [cyril]
... in June, the CSS WG sent a comment to Unicode, that it is not good for the Web
16:36:58 [cyril]
... because if someone does not have the right font, they wont see the variation
16:37:14 [cyril]
... from the perspective of people concerned about open standards, it's a mess
16:37:32 [cyril]
... in Japan it works but in the long term it's going to be a problem
16:37:46 [cyril]
... especially communicating outside of Japan
16:38:25 [cyril]
JF: METI decided to define the Character Information Platform and created a committee to create a character set
16:38:42 [cyril]
RI: is it defining glyphs and variation ?
16:38:46 [cyril]
JF: yes
16:38:59 [cyril]
... the result is a widely available font
16:39:02 [jun]
16:39:20 [cyril]
... the size of the font is 30 MB in OTF
16:39:44 [cyril]
... the number of glyphs is over 58 K
16:39:56 [cyril]
CL: 30 MB is zipped
16:40:02 [cyril]
... and 54 MB otherzise
16:40:11 [cyril]
JF: the name of the font is IPA
16:40:35 [cyril]
Information Technology Promotion Agency
16:40:46 [cyril]
... they provide the list of the characters defined
16:40:48 [jun]
16:41:15 [cyril]
... the table has an image over every glyph provided in SVG format
16:41:25 [cyril]
you can click on each image to get the SVG version
16:41:31 [cyril]
... using the SVG font mechanism
16:42:24 [cyril]
CM: one of the limitation of SVG, is that there wouldnt be ways of defining variations
16:42:30 [cyril]
CL: there would using ligatuers
16:42:44 [cyril]
JD: there is a difference between ligatures and variations
16:42:49 [cyril]
... spacing breaks ligatures
16:42:57 [cyril]
JF: it's a practical way
16:43:01 [cyril]
JD: no it breaks
16:43:12 [cyril]
... OpenType has a mechanism
16:43:17 [cyril]
... that's practical
16:43:24 [cyril]
... it's not gsub but cmap
16:43:40 [cyril]
... base character + selector = glyph
16:43:57 [cyril]
... there are several cases were ligatures are split (letter spacing)
16:44:19 [cyril]
... sometimes ligatures must be turned of
16:44:24 [cyril]
16:45:02 [cyril]
RI: I don't understand the difference between handling lam-alif ligatures and variations
16:45:24 [cyril]
JD: there is a distinction between required ligatures and other ligatures
16:45:45 [cyril]
CL: it would be futile to add i18n features to SVG, it would be huge
16:46:14 [cyril]
DS: and just information about required ligatures only
16:46:14 [cyril]
CL: maybe
16:46:25 [cyril]
DS: I agree that there is an existing mechanism
16:46:46 [cyril]
... but we could find another one
16:47:00 [cyril]
CL: I was pleased to see that the publication provides the font and the mapping
16:47:21 [cyril]
JD: but again the problem is that the publishing industry follows standards by Adobe
16:47:38 [cyril]
... and because of the way this has been registered, there are problems
16:48:19 [cyril]
... we made a comment to Unicode to not have a loose association
16:48:43 [cyril]
JF: another interesting part is the creation of a new technical WG to perform demonstration experiments
16:48:48 [cyril]
... using that font
16:48:54 [cyril]
... I'm the chair of the WG
16:49:12 [cyril]
... with vendors like Microsoft, Mozilla, Google
16:49:34 [cyril]
... on the demonstration system, we are planning to use SVG fonts for non UCS code points
16:49:43 [cyril]
... and we plan to have a WOFF version of the font
16:50:13 [cyril]
... we will probably discuss how we can split the font so that the browsers download only the required glyphs
16:50:28 [cyril]
RI: are you subsetting based on the document used ?
16:50:40 [cyril]
JF: based on unicode-range
16:50:58 [cyril]
RI: you might have then a document using a character that is not in the font
16:51:38 [cyril]
JD: I'm interested in trying to improve the practicality of the subsetting
16:51:44 [cyril]
... you have to put a long list
16:51:57 [cyril]
... but if you group with the most used first and then the least used
16:52:20 [cyril]
... is there a way to decide on names for the ranges
16:52:22 [Suresh]
Suresh has joined #svg
16:52:52 [cyril]
... I've asked Google to try and analyse the number to come with on the Web in Japanese what are the rankings
16:53:50 [cyril]
CL: the meaning of based character + IVS was not defined so these variations won't appear in the ranking
16:54:12 [cyril]
JD: as long as the base character was defined you will get them
16:54:46 [cyril]
CM: for this demonstration, practically, generating a WOFF font might be a good idea
16:55:11 [cyril]
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
16:55:29 [cyril]
CL: there are things that OTF does that SVG does not
16:55:42 [cyril]
... and there are things that SVG fonts can do but not OTF
16:55:54 [cyril]
... there is an effort to put SVG outlines in OTF
16:56:15 [cyril]
... that's how we get the best of both worlds
16:56:16 [cyril]
... including multi-colored, animated fonts
16:56:32 [cyril]
... WOFF brings compression, subsetting and license and metadata
16:57:24 [cyril]
JD: the format is not important, but not all browsers support the type 14 of cmap
16:57:43 [cyril]
... not webkit, IE9 does, some version of firefox does
16:58:20 [cyril]
EF: most of this stuff is handled in a platform specific platform not generically in Webkit
16:59:01 [cyril]
JD: for the support in browsers you need to have wide availability of the font and it has to be small size for phones
16:59:17 [cyril]
CM: if you are looking for format, there is not a single one
16:59:33 [cyril]
JF: we already decided on OTF but we want to test other formats
16:59:45 [cyril]
CL: what about Opera and Type 14 cmap ?
16:59:54 [cyril]
ED: I'm not sure
17:00:12 [cyril]
JD: when you subset, instead of have 1 font you have 10
17:00:46 [cyril]
... the first one has the 2K most frequent characters
17:01:23 [cyril]
... in unicode-range, you declare that you don't have the characters outside the range
17:01:47 [cyril]
RI: if you split a 54 MB font in 10, you still have large fonts
17:02:02 [ed]
ACTION: ed to check the status of opera support for type 14 CMAP in opentype fonts
17:02:02 [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].
17:02:11 [cyril]
JD: frequency is very important to manage the size
17:02:30 [cyril]
JF: we want to study the feasability of downloadable fonts in Japan
17:02:44 [cyril]
JD: it would be useful to know the frequency of character data
17:03:01 [cyril]
CL: in practice, you want to split the font into 100 of fonts
17:03:41 [cyril]
Topic: Mapping Taskforce / Tiling and Layering
17:04:27 [cyril]
ST: I'd like to share some information on the Mapping Taskforce
17:04:46 [cyril]
... Tiling and Layering is a fonctionality for Mapping
17:04:52 [stakagi]
17:05:00 [ChrisL]
ChrisL has joined #svg
17:05:19 [cyril]
... I divided in 3 categories
17:05:28 [ChrisL]
rrsagent, this meeting spans midnight
17:05:34 [ChrisL]
rrsagent, here
17:05:34 [RRSAgent]
17:05:39 [cyril]
... markup language, fonctionality and UI of the browsers and last API
17:06:10 [cyril]
... some topics were discussed in F2F last week
17:06:11 [ChrisL]
rrsagent, make logs public
17:06:16 [cyril]
... I appended my comments to each items
17:06:41 [stakagi]
17:07:25 [stakagi]
17:08:13 [stakagi]
17:09:38 [cyril]
CC: why use the <animation> element instead of <use> or <image>?
17:37:44 [RRSAgent]
RRSAgent has joined #svg
17:37:44 [RRSAgent]
logging to
17:38:46 [cyril]
RESOLUTION: Richard must have a Happy Birthday !
17:39:15 [cyril]
DS: one of the use besides mapping is for High Res photos for medical imaging data
17:39:55 [cyril]
ACTION: Doug to contact OpenStreetMap people to participate in the Mapping TF
17:39:55 [trackbot]
Created ACTION-3173 - Contact OpenStreetMap people to participate in the Mapping TF [on Doug Schepers - due 2011-11-11].
17:40:26 [cyril]
DS: it might make sense to have it as a community group also
17:40:30 [cyril]
17:46:59 [r12a]
r12a has joined #svg
17:47:50 [r12a]
r12a has joined #svg
17:48:08 [si-wei]
si-wei has joined #svg
17:50:42 [r12a]
r12a has joined #svg
17:57:25 [jay]
jay has joined #svg
17:58:16 [jay]
Present+ Jongyoul_Park
18:07:40 [r12a]
r12a has joined #svg
18:08:05 [jdaggett_]
jdaggett_ has joined #svg
18:08:41 [ed]
scribeNick: ed
18:08:46 [ed]
topic: testing
18:09:13 [ed]
CL: automated script type testing
18:09:36 [ed]
... new w3c testing reporting framework, being developed
18:09:44 [ed]
... gets automatic reporting back
18:10:03 [ed]
CM: different to the test harness thing?
18:10:18 [ed]
CL: yes
18:10:28 [ed]
CM: someone should have a look at the existing frameworks to figure out how we can use them
18:10:44 [ed]
CL: i have some experience with that
18:11:14 [jen]
jen has joined #svg
18:11:14 [ed]
ACTION: CL to investigate testing template needs for the new test system
18:11:15 [trackbot]
Created ACTION-3174 - Investigate testing template needs for the new test system [on Chris Lilley - due 2011-11-11].
18:11:24 [ed]
CL: already discussing how this should work for svg
18:11:45 [ed]
CC: linking from tests to spec?
18:12:11 [ed]
CL: yes, you have to edit some metadata to get that, but there's a script that inserts the tests into the spec
18:12:27 [ed]
s/tests into/links to the tests into/
18:12:50 [ed]
CM: when people create tests they should link to the spec
18:13:00 [ed]
CL: yes, the other way around would be harders
18:13:43 [ed]
... when we create a setup it will generate a harness automatically
18:14:12 [ed]
... it gives us pass/fail buttons for manual test reporting
18:14:20 [ed]
... you can also import results from a textfile
18:14:57 [ed]
... stats are provided, you can run per chapter, most needed tests (least tested)
18:15:12 [ed]
CM: what's the current state of running reftests?
18:15:20 [ed]
CL: not sure about that, need to investigate
18:15:30 [ed]
CM: what's teh scope of the browser testing group?
18:15:37 [ed]
CL: infinite, don't know
18:15:54 [ed]
CM: would be good for automation
18:16:03 [ed]
... would be good to look into
18:16:30 [ed]
... svg might need special API's, would be good if someone from here was in that group
18:16:44 [ed]
... TA you're in that group right?
18:16:46 [ed]
TA: yes
18:17:18 [ed]
CM: would be good to sort out testing now so that we can start writing tests while developing the new specs
18:17:50 [ed]
CL: we will have a good start if we import the existing testsuite
18:18:11 [ed]
CM: right, but it will still need to go through review again
18:18:40 [ed]
CL: at 12pm we'll have a guy from nvidia to talk about 2d graphics features
18:19:14 [ed]
... alex danilo mentioned this new nvidia API at svg open
18:19:25 [ed]
... we'll hear more about how svg could utilise this
18:19:38 [ed]
... let's return to the svg2 requirements list
18:19:46 [ed]
topic: svg2 requirements
18:20:11 [heycam]
18:20:12 [ed]
CM: polar coordinates for paths
18:20:44 [ed]
CC: before we dig in, we're still getting requests for features, how should we deal with them?
18:20:53 [ed]
DS: maybe we should use bugzilla
18:21:14 [ed]
CC: yes, but is there a cutoff date for new reqs?
18:21:36 [ed]
DS: we should use bugzilla, one feature per request
18:21:48 [ed]
... avoid the long lists in one email
18:21:57 [ed]
... and it gives us trackability
18:22:27 [ed]
CM: it's unlikely that reqs will come in before we're done going through the list we have atm
18:22:42 [ed]
... unlikely that we can't handle any additional requests
18:22:59 [ed]
CC: if we get one or two sure, but if we get a lot of them?
18:23:13 [ed]
CM: after we've settled on the list of reqs, that's a good cutoff point
18:23:25 [ed]
... probably ok to keep gathering reqs for a while longer
18:23:46 [ed]
CM: ok, back to the issues list
18:23:53 [heycam]
18:23:55 [ed]
... this is DOH's proposal
18:24:13 [ed]
... remember seeing a script impl of his proposal
18:24:37 [ed]
... not grounded in use-cases
18:24:46 [ed]
... not sure it's worth the complexity
18:24:57 [ed]
... it's reasonably simple to do in script
18:25:47 [ed]
... there's another proposal to be able to setup a polar coordinate system
18:26:21 [ed]
CC: the whole issue with scripting, there are envs where scripting is not enabled
18:26:38 [ed]
... need to be sure we don't disregard it if it's an important use-case
18:26:44 [ed]
... fonts, etc
18:26:57 [ed]
... not sure if this is the case here
18:27:11 [ed]
JY: what does it do?
18:27:41 [ed]
CM: being able to easily create polygons, without having to figure out exact points and so on
18:27:54 [ed]
... i think this one is probably not so important
18:28:02 [ed]
... does everyone agree with that?
18:28:17 [ed]
(silence in the room)
18:28:32 [ed]
DS: such a small script, we could just add it, but it doesn't seem broadly useful
18:28:42 [ed]
JY: yes
18:28:58 [ed]
TA: it does more than just the polygons
18:29:20 [ed]
DS:i had a competing proposal
18:29:34 [ed]
... basically a polygon thing, but it wasn't using polar coordinates
18:29:45 [ed]
... i think it could be useful
18:29:49 [Rossen]
Rossen has joined #svg
18:30:37 [ed]
DS: maybe broaden the scope to investigate improving polygon
18:30:52 [ed]
CM: don't the path extensions already address this?
18:31:25 [ed]
CC: the script is so small, but we still need to test, which is more work
18:31:52 [ed]
... even if the implementation is small too
18:32:14 [ed]
DS: the number of things you can do with it means it needs more testing
18:32:15 [ed]
TA: if you need total coverage yes
18:32:27 [ed]
... you can machine generate tests, so it's not impossible
18:32:40 [ed]
... must be justified by the functionality though
18:33:11 [ed]
CM: i'd be ok with a req for us to make it easier draw and animate regular polygons
18:33:26 [ed]
DS: another aspect is that there are visualizations that are polarbased
18:33:34 [ed]
... would be nice if we could do those easily
18:34:20 [ed]
CL: if we introduce polar coordinates we'll have to worry about how that works with the existing transforms and so on
18:34:50 [ed]
... we also have the ref transform, so it can get complex
18:35:20 [ed]
CM: stars are not regular polygons, but they are similar
18:35:27 [ed]
CC: you can do them with the polar element
18:35:35 [shepazu]
18:36:13 [ed]
CL: in 1996 i was given an action to draft polygon which had number of corners etc, but it was dropped
18:36:39 [ed]
DS: (shows the starmaker script)
18:36:46 [ed]
... not a concrete proposal
18:37:17 [ed]
CM: do we want to broaden the scope outside of regular polygons or not?
18:37:43 [ed]
... even for regular polygons, you might have a stopsign or something, but how often would it be useful?
18:38:15 [ed]
DS: stars would be useful, need the centerpoint for easily translation and animation
18:38:43 [ed]
CM: if the improved path commands would solve the usecase...
18:38:59 [ed]
CC: right, it's not so important how it's solved at this stage
18:39:16 [ed]
CM: might open the door for something too complex
18:40:29 [ed]
RESOLUTION: make it simpler to constuct regular polygons and stars
18:41:12 [cyril]
RRSAgent, pointer please
18:41:12 [RRSAgent]
18:41:15 [ed]
CM: next, introduce elementbased path syntax
18:41:16 [heycam]
18:41:51 [ed]
DS: have written a prototype, don't know where it is now
18:42:02 [ed]
... pretty easy to collapse the syntax back to a path
18:42:11 [ed]
... the EXI group wants the elementbased syntax
18:42:32 [ed]
... another proposal was to... (doug draws on whiteboard)
18:43:30 [ed]
<path d="M 0 0..., seg(#somepath) Z"/>
18:43:44 [ed]
... this would make it possible to do composite paths
18:43:55 [ed]
... not exactly what the EXI group wanted though
18:44:20 [ed]
... not clear EXI is the way ppl push content to the web, but we might want to make a module for it
18:44:40 [r12a]
r12a has joined #svg
18:44:45 [ed]
... that might create a division since the content might not work in browsers
18:45:16 [ed]
... if we do this we need to define a normalization algorithm so that we can go from one to the other syntax
18:45:34 [ed]
TA: i like it, because generating a path string is a bit annoying
18:45:45 [jun]
18:45:55 [ed]
CC: js libraries help you with some of this, have path helpers
18:46:13 [ed]
... raphael, d3 etc
18:47:14 [ed]
(DS gives an example of element syntax on whiteboard)
18:47:33 [ed]
DS: each element has their own attributes
18:47:47 [ed]
CC: the cubic element could be used for the gradient meshes
18:48:35 [ed]
... 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
18:49:14 [ed]
CM: it will be slow if the DOM is too big
18:49:20 [ed]
TA: my use-case is to make a non-sucky path API
18:49:57 [ed]
CM: it's not clear EXI is the solution
18:50:14 [ed]
TA: it's for XML, not for html
18:50:25 [ed]
... unless it's extended
18:50:44 [ed]
CC: they want a specific coding for elements and attributes for compression
18:51:01 [ed]
CM: so they can compress based on the schema
18:51:34 [ed]
TA: don't think svg is a big deal for EXI
18:51:43 [ed]
JF: EXI can be applied to any xml content
18:51:53 [ed]
... we are discussing how to apply EXI to html content
18:52:03 [ed]
DS: it would still have to be wellformed html?
18:52:18 [ed]
CC: but html is generally small, however svg maps can be huge
18:52:35 [ed]
JF: maps contain a lot of path data
18:52:57 [ed]
TA: so we could make an appendix covering this, or a module
18:53:02 [ed]
DS: yes for transport
18:53:06 [dbaron]
dbaron has joined #svg
18:53:48 [r12a]
r12a has joined #svg
18:54:19 [ed]
CL: a path with an attribute could be expanded out to a shadow dom, let's you fiddle with it
18:54:28 [ed]
CC: could be done with a nice path API
18:54:56 [ed]
DS: declarative animation of subpaths
18:55:37 [jun]
18:55:40 [ed]
JF: MS silverlight provided two ways to describe the path information
18:56:13 [ed]
DS: all children of a path could be discarded by the DOM and put into the attribute?
18:56:20 [ed]
... the DOM doesn't allow that
18:56:33 [ed]
CM: would feel weird to me
18:57:17 [heycam]
18:58:14 [ed]
DS: there are modes in the html5 parser where it inserts tbody
18:58:31 [ed]
... there's precedent for it
18:58:42 [ed]
CM: i'd be ok with having an appendix for EXI
18:59:12 [ed]
... but i don't see allowing EXI to compress svg is enough to require implementations to support this syntax
18:59:23 [ed]
CC: maybe if it got more popular?
19:00:42 [ed]
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
19:01:13 [ed]
DS: yoking this to a better path api would be useful
19:01:46 [ed]
CC: we'd have to make sure the element syntax is better for EXI, there are many ways we could chose the syntax
19:01:57 [ed]
DS: so we should ask the EXI group about that
19:02:20 [ed]
... if we do this at all I'd like us to be strict about the normalization
19:02:35 [ed]
... so that implementations know what to do with this syntax
19:02:59 [ed]
CM: i would expect browsers to just put it in the DOM and not do anything wiht it
19:03:13 [ed]
DS: worst of both worlds
19:03:24 [cabanier]
Is there a conference code for today's meeting?
19:04:33 [ed]
CM: if it's alot of overhead to transmit documents like this then we don't want ppl to use this
19:07:25 [heycam]
Zakim, room for 3?
19:07:26 [ed]
ACTION: JF to talk to the EXI WG about requirements for element based syntax for svg
19:07:27 [Zakim]
ok, heycam; conference Team_(svg)19:07Z scheduled with code 26632 (CONF2) for 60 minutes until 2007Z
19:07:27 [trackbot]
Created ACTION-3175 - Talk to the EXI WG about requirements for element based syntax for svg [on Jun Fujisawa - due 2011-11-11].
19:08:24 [Zakim]
Team_(svg)19:07Z has now started
19:13:03 [ed]
topic: Hardware acceleration
19:14:44 [ed]
(Neil Travet from nvidia gives presentation about GPU acceleration of svg)
19:14:59 [ed]
NT: nvidia will get more involved in the svg wg
19:15:34 [ed]
... we've created an extension to opengl to offload path rendering to the GPU
19:15:41 [ed]
... up to 100 times faster
19:15:55 [ed]
... without sacrificing quality, instead improving it
19:16:16 [ed]
... can save power, good for mobiles
19:16:18 [ed]
... mixes well with 2d and 3d
19:16:37 [ed]
... shipping today, all desktop gpus have this in their installed drivers
19:16:42 [ed]
... coming to mobile soon
19:16:48 [ed]
... it's a stencil then cover approach
19:17:42 [ed]
... once the stencil is genrated it can be used for rendering
19:17:54 [ed]
... has full support for text
19:18:33 [ed]
... can avoid approximations when running on gpu, improves quality
19:18:48 [ed]
... more accurate
19:19:13 [ed]
... doesn't have to do subdivison or tesselation, stroking is exact, caps, dashing supported
19:19:51 [ed]
... antialiasing uses jitter pattern
19:20:29 [ed]
... avoids some artefacts, overlaps and holes
19:21:24 [ed]
... (compares performance software vs hardware)
19:22:08 [ed]
... hw is often 5 times faster, but it's never slower than software
19:22:20 [ed]
CC: coat of arms example is slower no?
19:22:29 [ed]
NT: not slower, it's the same speed
19:25:56 [jun]
jun has joined #svg
19:26:12 [ericm]
ericm has joined #svg
19:26:15 [stakagi]
stakagi has joined #svg
19:26:20 [thorton]
thorton has joined #svg
19:26:33 [ed]
... we have started createing an experimental svg renderer
19:26:33 [ed]
... missing some parts
19:26:42 [ed]
... some new features, advanced stroking, sRGB correct rendering
19:26:44 [ed]
... 4x4 transforms
19:26:50 [ed]
... mixing text, 3d and paths, proper path perspective transforms
19:26:52 [ed]
DS: what about filters?
19:26:56 [ed]
CM: has to work with opengl anyway, so write shaders in GLSL
19:27:00 [ed]
NT: yes, the css shaders proposal uses that so yes
19:27:57 [ed]
DS: do you do performance testsuites?
19:28:14 [cyril]
cyril has joined #svg
19:28:21 [ed]
... w3c haven't had any, but we might want to consider performance a test criteria
19:28:26 [efidler]
efidler has joined #svg
19:28:34 [ed]
NT: we have that discussion in the khronos group
19:28:54 [ed]
... but who are we to judge the use-cases, depends on other requirements, not the same for everyone
19:29:25 [ed]
DS: sure, but just being able to test things that are meant to be performant
19:29:45 [ed]
NT: but you'd have to be careful to not construct a benchmark
19:29:49 [stakagi]
About projective transforms, Is Mercator Projection possible?
19:30:12 [ed]
NT: not sure
19:31:21 [ed]
CM: one of the things that come up when discussing features is whether things are easily hw acc
19:31:30 [ed]
... so what's possible to do in graphics libs
19:31:55 [shepazu]
shepazu has joined #svg
19:31:59 [ed]
... would be good to know if design decisions we do would make things better or worse for hw acc
19:32:22 [ed]
... also whether it will take time before drivers support these things
19:33:26 [ed]
NT: i'm pushing nvidia to join svg wg
19:33:50 [ed]
... to have better communcations with the group
19:34:44 [ed]
DS: is intel a member of khronos?
19:34:47 [ed]
NT: yes
19:35:11 [ed]
DS: we could consider making a joint deliverable between khronos and w3c
19:35:25 [ed]
NT: the value of khronos is that all the hw vendors are there
19:36:26 [ed]
EF: what do the other vendors think of the nvidia path extension proposal?
19:36:49 [ed]
NT: it's a little bit soon for mobile
19:36:56 [ed]
... but it's desktop today
19:37:37 [ed]
EF: for the vendors that have the capability do they support hte proposal?
19:38:00 [ed]
NT: we haven't officially proposed it yet, we're waiting for feedback
19:38:21 [ed]
EM: motorola mobility is really interested in this
19:38:49 [ed]
CM: can direct2d do similar things?
19:38:51 [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?
19:38:53 [jdaggett_]
jdaggett_ has joined #svg
19:38:56 [r12a]
r12a has joined #svg
19:39:02 [ed]
JY: i don't know the details, but fir filter effects yes
19:39:34 [ed]
NT: the test app uses AA in the gpu
19:39:44 [ed]
... 16 bits of stochastic AA
19:40:19 [ed]
RC: the AA implementation looks interesting, seems to require less memory
19:40:48 [ed]
CM: we discussed seams in svg rendering the other day, and the person asked for FSAA to be added
19:41:00 [ed]
... are there other good approaches we should consider?
19:41:12 [ed]
NT: reached the end of my expertise, sorry
19:41:50 [ed]
DS: having you help us with testing and creating tests
19:41:55 [ed]
... would be good
19:42:03 [ed]
NT: yes, we could help out with that
19:42:22 [ed]
DS: mutually beneficial spiral yes, for hw vendors too
19:43:13 [ed]
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
19:43:13 [shepazu]
s/testing and creating tests/testing and creating tests, and reusing our tests/
19:43:36 [ed]
CM: would be great to have mark join the group
19:44:20 [ed]
DS: would be good to get some hw people on the wg
19:44:44 [ed]
--- break for lunch ---
19:44:49 [ed]
resumes at 2pm
19:49:54 [cyril_]
cyril_ has joined #svg
19:55:49 [stakagi]
stakagi has joined #svg
20:31:19 [TabAtkins_]
TabAtkins_ has joined #svg
20:39:15 [stakagi]
stakagi has joined #svg
20:42:54 [thorton]
thorton has joined #svg
20:54:53 [efidler]
efidler has joined #svg
20:55:14 [heycam]
Zakim, status?
20:55:14 [Zakim]
I don't understand your question, heycam.
20:55:18 [heycam]
Zakim, code?
20:55:18 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200, heycam
20:55:24 [heycam]
Zakim, who is on the call?
20:55:24 [Zakim]
On the phone I see no one
20:55:39 [Zakim]
Team_(svg)19:07Z has ended
20:55:41 [Zakim]
Attendees were
20:56:15 [heycam]
Zakim, room for 3?
20:56:16 [Zakim]
ok, heycam; conference Team_(svg)20:56Z scheduled with code 26632 (CONF2) for 60 minutes until 2156Z
20:56:42 [Zakim]
Team_(svg)20:56Z has now started
20:57:02 [shepazu]
shepazu has joined #svg
20:57:13 [ericm]
ericm has joined #svg
20:57:55 [Tavmjong]
20:59:27 [jun]
jun has joined #svg
21:00:03 [TabAtkins_]
TabAtkins_ has joined #svg
21:01:17 [vhardy]
vhardy has joined #svg
21:01:48 [Rossen]
Rossen has joined #svg
21:02:29 [r12a]
r12a has joined #svg
21:02:35 [Bert]
Bert has joined #svg
21:02:40 [r12a]
r12a has left #svg
21:04:39 [jen]
jen has joined #svg
21:04:43 [ChrisL]
ChrisL has joined #svg
21:05:06 [ChrisL]
scribenick: ChrisL
21:05:11 [ChrisL]
topic: svg spec editing
21:05:23 [Tavmjong]
21:05:52 [ChrisL]
tb: spent some time working on this document, wrote upmy experiences
21:06:15 [ChrisL]
... goal A clearly written SVG 2.0 specification that also happens to look good.
21:06:26 [ChrisL]
... css3 fons spec used as a model
21:06:39 [ChrisL]
... changed stylesheet, used css3 values style
21:06:45 [ChrisL]
... added an annotation class
21:07:11 [ChrisL]
... preserves history of the reason for decisions
21:07:33 [ChrisL]
cm: switched off by default and alternate stylesheet to show?
21:07:37 [ChrisL]
tb: yes
21:07:49 [ChrisL]
tb: added some svg-specific styling also
21:08:32 [ChrisL]
... publish.xml changed, replaced tables with divs which style easier. updated figure handling to allow captions
21:08:44 [ChrisL]
cm: looks a lot more like the css fonts figures
21:09:17 [ChrisL]
tb: current spec lacks a lot of figures
21:09:39 [ChrisL]
tb: unified style, some graphics were tiny others huge, and the colours all over the place
21:09:58 [ChrisL]
... for svg graphics, updated to remove dtd and change titles to be useful
21:10:16 [ChrisL]
... attr lists are all crammed together, replaced by paragraphs
21:10:41 [ChrisL]
... rather than line breaks
21:11:24 [ChrisL]
... much more readable
21:11:33 [ChrisL]
cm: never liked the old styling anyway
21:12:19 [cyril]
21:12:24 [ChrisL]
cm: vincent has also experimented with specs, see his css transforms spec as an example
21:12:41 [ChrisL]
... started from same stylesheet, made more changes
21:12:58 [ChrisL]
... we need to discuss together and settle on a consistent spec style
21:13:48 [ChrisL]
cc: so you changed to a less obvious gradient, light purple to white rather than red to green
21:13:58 [ChrisL]
... previously you could see the exact stops
21:14:23 [ChrisL]
... not against making colours less jarring but you should still see the differences between the colours
21:14:56 [ChrisL]
cm: do like the additionalfigues, they explain it well
21:15:22 [ChrisL]
ed:better if h & v lines aligned with pixel grid so they are sharp
21:16:05 [jdaggett_]
jdaggett_ has joined #svg
21:16:41 [ChrisL]
cl: i think they are just grey lines, not intended to be black
21:17:18 [ChrisL]
cm: what about including inline figures
21:17:42 [dbaron]
dbaron has joined #svg
21:17:48 [ChrisL]
tb: some will not render correctly in browsers, if they use new features
21:18:13 [ChrisL]
cm: the circlesexampleis like the nvidia demo earlier today, bunched up radial gradients
21:18:42 [ChrisL]
cl: well known case that depends on sub-pixel precision
21:18:55 [ChrisL]
tb: I added solid solid color
21:19:01 [ChrisL]
cm: we resolved to add that?
21:19:13 [ChrisL]
(several: yes)
21:19:24 [ChrisL]
cc: its below where we got to in requirements list
21:20:02 [ChrisL]
tb: is there a list?
21:20:17 [ChrisL]
cm: added to the wiki page, it links to the minutes
21:20:41 [ChrisL]
... probably not what you want to link to from the spec annotation though
21:20:45 [plinss]
plinss has joined #svg
21:20:48 [ChrisL]
tb: what would be better
21:20:51 [ChrisL]
cc: its nice
21:21:11 [ChrisL]
cm: extra figures are great, colours can be discussed
21:21:15 [ChrisL]
... general direction of spacing etc is good
21:21:45 [ChrisL]
cm: may need some more radical restructuring. in terms of dom rather than how markup is rendered
21:21:55 [ChrisL]
.... ut that does not present the current improvements
21:22:12 [ChrisL]
cc: dom interfaces remain in the chapter?
21:22:15 [ChrisL]
cm: yes and should be more prominent in each section
21:22:31 [ChrisL]
cm: so tav keep on experimenting, this is helpful
21:23:03 [ChrisL]
ed: so we are going with the testing framework, might be nice to annotate things to keep them separate for the spec
21:23:17 [ChrisL]
... maintained by bugzilla and then imported in
21:23:46 [ChrisL]
ed: concern on the annotations getting out of date
21:24:11 [ChrisL]
cm: like the annotations that say what is new
21:24:56 [ChrisL]
cm: see issue 4 in linear gradients
21:25:18 [ChrisL]
"Could this be written in a less legalese way? "
21:26:13 [ChrisL]
cc: lacuna value was used to express that in tiny1.2
21:26:27 [ChrisL]
cl: yes and I see erik suggested adopting that in 2 - I agree
21:27:23 [ChrisL]
cc: we need a ara upfront in the spec explaining lacuna, default, inititial etc
21:27:37 [cyril]
s/a ara/a paragraph/
21:28:36 [ChrisL]
cl: we need to be precise, don't want to be short and imprecise
21:28:48 [ChrisL]
cm: great work tav
21:29:02 [ChrisL]
cc: you have not put this in mercurial?
21:29:11 [ChrisL]
tb: no, not yet and not sure how to
21:29:22 [ChrisL]
cm: jwatt wrpte it up in a wiki page
21:29:32 [cyril]
21:29:38 [ChrisL]
21:29:57 [ChrisL]
ds: talking with vincent about this restyling?
21:30:14 [ChrisL]
cm: yes he is, we mentioned that earlier
21:30:15 [ChrisL]
ds: should have a single style
21:30:25 [ChrisL]
cl: yes the point was made earlier
21:30:44 [ChrisL]
cc: intereting the two editing companies are providing styles (adobe and inkscape)
21:30:54 [ChrisL]
21:31:01 [ChrisL]
ds: like the annoations
21:31:13 [ChrisL]
tb: by default the style for those is turned off
21:32:11 [ChrisL]
ds: any spec freature we put in the spec should have ids so they can be linked to
21:32:25 [ChrisL]
21:32:39 [ChrisL]
cm: chris was saying earlier about generating links to tests
21:33:57 [ChrisL]
cl: sync issue with maintaining info in multiple places
21:34:28 [ChrisL]
ds: scheme css wg is usig is not fine grained enough. spec section is good but specific assertions is much better
21:34:59 [ChrisL]
cl: in woff the first link is to section and subsequent ones to specific testable assertions
21:35:11 [ChrisL]
cc: so where are the rules for editing?
21:35:16 [ChrisL]
ds: wiki page
21:35:28 [ChrisL]
... and we should work on this with other groups as well
21:35:59 [ChrisL]
cl: we need to document the existing spec first
21:36:45 [ChrisL]
ds: yes, but we have traction in several groups already, especially for apis and events - things we all want to mark up
21:37:58 [ChrisL]
cl: the text "issue 6" etc is css text so its not searchable or copy/pastable
21:38:16 [ChrisL]
ds: they should link to actual isues in tracker
21:38:40 [ChrisL]
cm: and when you delete one the others would renumber
21:38:46 [ChrisL]
21:39:47 [ChrisL]
tb: some of those issues would not be in tracker
21:39:55 [ChrisL]
cl: prefer they are all in tracker
21:40:18 [ChrisL]
ds: for anything like that, it needs to link to a bug tracker
21:40:59 [ChrisL]
cm: to capture some initial rules, could you start a wiki page that lists these?
21:41:30 [ChrisL]
cl: and cameron please document or link to the xml build system docs
21:41:59 [heycam]
ACTION: Tav to write up wiki page documenting spec writing rules, like annotations
21:41:59 [trackbot]
Created ACTION-3176 - Write up wiki page documenting spec writing rules, like annotations [on Tavmjong Bah - due 2011-11-11].
21:42:39 [ChrisL]
cm: good to have a go at incorporating this into the repository and try to build it
21:43:00 [ChrisL]
action; cameron to ensure current markup rules linked from tav's wiki page on editing
21:43:20 [ChrisL]
action: cameron to ensure current markup rules linked from tav's wiki page on editing
21:43:21 [trackbot]
Created ACTION-3177 - Ensure current markup rules linked from tav's wiki page on editing [on Cameron McCormack - due 2011-11-11].
21:44:13 [ChrisL]
cm: in 15 minutes we have web components work discussion, starts at 3pm. so before, we could look at one or two requireents issues
21:44:21 [ChrisL]
topic: requirements once more
21:44:30 [cyril]
21:44:52 [ChrisL]
topic: path arcto with 360 arcs
21:45:11 [cyril]
zakim, draft minutes
21:45:11 [Zakim]
I don't understand 'draft minutes', cyril
21:45:21 [cyril]
RRSAgent, draft minutes
21:45:21 [RRSAgent]
I have made the request to generate cyril
21:45:44 [ChrisL]
ed: might fall out of the pattern elements we discussed previously
21:45:45 [cyril]
RRSAgent, pointer
21:45:45 [RRSAgent]
21:45:57 [ChrisL]
cm: maybe turtle graphics help here
21:46:13 [ChrisL]
... good to accept this requirement
21:46:22 [ChrisL]
ed: express as making it possible to make a complete circle on a path
21:46:34 [cyril]
RRSAgent, make minutes public
21:46:34 [RRSAgent]
I'm logging. I don't understand 'make minutes public', cyril. Try /msg RRSAgent help
21:46:36 [ChrisL]
cm: boraoded to makeing arcs easier
21:48:14 [ChrisL]
cl: (explains history of current arc command)
21:48:44 [ChrisL]
cm: broadened to makeing arcs easier
21:49:46 [ChrisL]
jf: can confirm hosting of SVG in Australia
21:50:37 [ChrisL]
cm: turtle graphics will break the "command generates new current point" paradigm
21:50:45 [ChrisL]
cl: don't like that
21:51:14 [ChrisL]
resolution: make arcs in paths easier
21:51:28 [ChrisL]
topic: polar element
21:51:31 [heycam]
21:51:54 [ChrisL]
cm: this is the fancy flowers one, previous one was polar coords inside a path
21:52:12 [ChrisL]
... this is an element that makes stars, etc
21:52:30 [ChrisL]
tb: inkscape has these sort of shapes
21:53:00 [ChrisL]
... good to include these
21:53:14 [ChrisL]
ds: but it can't animate them live in the browser
21:53:27 [ChrisL]
tb; also, native support would make our generated files smaller
21:54:17 [heycam]
21:54:27 [ChrisL]
cm: so, we resolved not to include this one in svg2 ....
21:55:22 [ChrisL]
... because although it can make some nice artistic effects the added complexity is rather specific and not so useful in the general case
21:55:41 [ChrisL]
resolved: wil not add a polar element in svg2
21:55:48 [ChrisL]
21:56:44 [ChrisL]
Topic: Define <shapePath> element
21:56:47 [heycam]
21:57:49 [ChrisL]
cl: this is positioning along a path, not warping along a path which we already rejected
21:58:13 [ChrisL]
ds: textPath lets to place a list of shapes along a path, as long as they are glyphs
21:58:19 [ChrisL]
... this is the same except not glyphs.
21:58:31 [ChrisL]
...not thought much about spacing and sizing issues
21:58:48 [Tavmjong]
Just got kicked off conference call... hour is up.
21:59:12 [ChrisL]
... this is a way of doing certain marker-like efects that markers can't do
21:59:29 [ChrisL]
zakim, room for 3?
21:59:31 [Zakim]
ok, ChrisL; conference Team_(svg)21:59Z scheduled with code 26631 (CONF1) for 60 minutes until 2259Z
21:59:50 [cyril]
21:59:50 [ChrisL]
(discussion of text along a path)
22:00:17 [ChrisL]
cc: gpac has this, text and shapes mixed along a path
22:00:29 [Zakim]
Team_(svg)20:56Z has ended
22:00:31 [Zakim]
Attendees were
22:00:54 [ChrisL]
ed:at opera we had a way to put graphics inside an anchor tag
22:00:57 [heycam]
Zakim, who is here?
22:00:57 [Zakim]
apparently Team_(svg)20:56Z has ended, heycam
22:01:12 [heycam]
Zakim, who is on the call?
22:01:12 [Zakim]
apparently Team_(svg)20:56Z has ended, heycam
22:01:21 [heycam]
Zakim, this svg
22:01:21 [Zakim]
I don't understand 'this svg', heycam
22:01:23 [heycam]
Zakim, this is svg
22:01:23 [Zakim]
ok, heycam; that matches Team_(svg)21:59Z
22:01:27 [heycam]
Zakim, who is on the call?
22:01:27 [Zakim]
On the phone I see no one
22:01:40 [Tavmjong]
22:01:43 [ChrisL]
ds: if we have textPath and shapePath these could take references to other eleents, rendered in order. could be text or shapes
22:02:13 [Tavmjong]
22:02:14 [ChrisL]
cc: need an anchor point per shape
22:02:21 [ChrisL]
cl: like baseline for glyphs
22:02:34 [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>/
22:03:14 [ChrisL]
cc: width of the object is the advance for the next object
22:03:23 [ChrisL]
... boundingbox most likely
22:04:18 [ChrisL]
rossen: its straightforward for some shapes, not clear for arbitrary shapes
22:04:36 [ChrisL]
cc: anythink like this in css?
22:04:50 [ChrisL]
rossen; no , was thinking of implementing textPath in IE
22:05:50 [ChrisL]
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
22:06:01 [ChrisL]
... autorotate or not
22:06:11 [ChrisL]
cc: like animateMotion
22:06:11 [ChrisL]
ds; yes
22:07:33 [ChrisL]
tb: Copies of the single yellow star are placed along a path. The star is deformed to follow the path.
22:07:46 [ChrisL]
ds: can repeat these things
22:08:17 [ChrisL]
... repeat n times or repeat to follow whole path
22:08:28 [ChrisL]
... can do custom dash patterns like this
22:09:14 [ChrisL]
cc: already possible to hack this, so a clear way forward would not have too much implementation cost. what are the use cases?
22:09:23 [ChrisL]
cm: markers not at endpoints
22:09:35 [ChrisL]
ds: railway tracks, custom pattersn eg for mapping
22:10:18 [ChrisL]
cl:electrical diagrams
22:11:11 [ChrisL]
ds; we brainstormed this at svg f2f a couple years ago but we were hung up on other work
22:11:31 [ChrisL]
... markers are not clickable, want these to be clickable
22:12:11 [ChrisL]
... click would say how far along the path and what the original object was and the repeat count
22:12:58 [ChrisL]
ds: putting text along this as well, like text on roads
22:13:30 [ChrisL]
cl: repeat groups
22:13:37 [ChrisL]
ds: scaling and non scaling
22:14:58 [ChrisL]
cm: want to resolve onuc&r not on syntax
22:15:21 [ChrisL]
cc: placing object on a path, mixing text and objects, and repeating. these are three separate things
22:15:47 [ChrisL]
cm: these are a bit like the deforming objects on a path
22:16:27 [heycam]
Scribe: Cameron
22:16:30 [heycam]
ScribeNick: heycam
22:16:37 [heycam]
s/onuc/on uc/
22:18:47 [heycam]
RESOLUTION: We will allow objects to be positioned along a path
22:22:17 [heycam]
cm: basically, this would be improved positioning of markers
22:25:58 [heycam]
cm: being able to place a diamond every 10 units along a path, for example
22:26:18 [heycam]
cc: similarities between markers and dashes
22:27:48 [heycam]
-- 10 minute break --
22:28:27 [efidler]
efidler has joined #svg
22:29:28 [Zakim]
Team_(svg)21:59Z has ended
22:29:29 [Zakim]
Attendees were
22:36:43 [jen]
jen has joined #svg
22:40:12 [heycam]
Topic: Component Model
22:40:17 [heycam]
DS: SVG has the 'use' element
22:40:23 [heycam]
... which has a concept of a shadow tree
22:40:29 [heycam]
... since it was an early idea, there were various problems with it
22:40:38 [plinss]
plinss has joined #svg
22:40:40 [heycam]
... problems with the DOM interface, underlying architecture, performance
22:41:14 [heycam]
... 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
22:42:42 [heycam]
TA: there are some fundamental parts of use that can be represented by Component Model semantics
22:42:57 [heycam]
... 'use' points at a template, and is rendered as the same way as you transplanted that template whereever the 'use' is
22:43:15 [heycam]
... shadow dom works the same way
22:43:24 [heycam]
... more specifically, 'use' doesn't actually have children, the shadow tree isn't really in the dom
22:43:26 [dglazkov]
dglazkov has joined #svg
22:43:50 [heycam]
... 'use' is supposed to be fast when spamming it in the dom
22:43:58 [dbaron]
dbaron has joined #svg
22:44:11 [heycam]
... that's not the case in implementations
22:44:23 [heycam]
... but we want it to be fast, and we want to satisify this case with shadow dom too
22:44:28 [heycam]
... we want to allow a "projected shadow"
22:44:34 [heycam]
... the template defines the "one and only" copy of the dom
22:44:39 [heycam]
... all the instances just pull a render tree from that
22:44:50 [heycam]
... they lay out as if it's there, but all dom/styling information comes from the one instance in the template
22:45:00 [heycam]
DG: all browsers are optimized to create and throw away render boxes
22:45:03 [heycam]
... dom, not so much
22:45:15 [heycam]
... the idea is that projected trees have one dom but can be rendered in multiple places
22:45:19 [heycam]
DS: can you change things?
22:45:25 [heycam]
TA: if you change it, it changes for everything
22:45:31 [heycam]
DG: with projected dom, there is no instance
22:45:46 [heycam]
TA: in svg, you can't tweak the instance dom either
22:45:56 [heycam]
... there's an instance tree, but you can only style the instance via inheritance from the 'use'
22:46:01 [heycam]
... all selector matching is done on the template itlsef
22:46:12 [heycam]
22:46:12 [heycam]
... this is the only complicated thing
22:46:13 [JanL]
JanL has joined #svg
22:46:14 [heycam]
... the styling part we want to figure out
22:46:23 [heycam]
... what amount of styling per instance is required, how we can do this in a sane manner
22:46:52 [plinss]
plinss has joined #svg
22:47:01 [plinss]
plinss has joined #svg
22:47:12 [heycam]
JY: I don't think our implementation is completely crazy as cloning everything, but not sure
22:47:51 [heycam]
DS: [ draws an example ]
22:49:12 [heycam]
[ people wanting to change little parts of a 'use'd tree, not just with simple inheritance overriding ]
22:49:18 [kaz]
kaz has joined #svg
22:49:27 [heycam]
TA: if we go with the simple, cheap, projected tree, where everyone gets their own render tree
22:49:34 [heycam]
... there's no styling allowed from the 'use' instance
22:49:37 [heycam]
... that's less than ideal
22:49:47 [heycam]
... how can we do this in a saner manner?
22:49:59 [heycam]
... doing inheritance from the 'use' is rather bad, since that works over the dom tree, not the render tree
22:50:18 [heycam]
... "pretending" you have a dom there, even if there isn't
22:50:18 [heycam]
... the situation for markers can be a bit saner
22:50:20 [plinss__]
plinss__ has joined #svg
22:50:43 [heycam]
... you can specify currentFill and currentStroke on dom nodes in the template, but they resolve differently depending on the instance
22:52:02 [heycam]
... if that's not insane, i want to see whether we can apply this to component model
22:52:24 [heycam]
CM: people haven't implemented currentFill/currentStroke property values yet
22:52:32 [heycam]
CC: one problem I found with 'use', you have to pass the whole inherited properties in
22:52:44 [heycam]
... I would rather have an explicit list of properties that you pass through
22:52:54 [heycam]
TA: don't allow the full set of properties
22:53:15 [heycam]
CC: or you use something we you can by default put all properties to initial value
22:53:55 [heycam]
TA: are used values resolved still with dom tree information? or is it a render tree thing?
22:53:59 [heycam]
DG: in webkit, it's when we're doing layout
22:54:32 [heycam]
... the key problem with the projected dom, you'll have multiple render trees, one dom, no way for them to resolve differently
22:54:39 [heycam]
TA: used values have to resolve differently
22:54:52 [heycam]
... 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
22:55:13 [heycam]
... if that works, we could specify a syntax for "used value" variables
22:55:17 [heycam]
... and let that pass data into the instances
22:56:30 [heycam]
CM: won't resolving 50% later mean you get wildly different boxes?
22:56:31 [heycam]
TA: not necessarily, used values are handled after layout
22:56:48 [heycam]
ED: what about a 'use' of a 'use'?
22:56:54 [heycam]
TA: that just falls out of the shadow dom model
22:57:12 [heycam]
ED: the other tricky thing is using an external document
22:57:13 [plinss]
plinss has joined #svg
22:57:15 [heycam]
TA: didn't know you could do that
22:57:25 [heycam]
s/using an/using elements from an/
22:59:37 [heycam]
DG: every rendering of the shadow tree, for a "normal" shadow tree, is backed by real dom nodes
22:59:44 [heycam]
... so that's cloning a dom subtree
22:59:59 [heycam]
... 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
23:00:21 [heycam]
DS: could there be the idea of a projected tree with decoration?
23:00:40 [plinss__]
plinss__ has joined #svg
23:00:55 [heycam]
TA: if we define a form of variables that only resolve at "used value" time, that will work
23:01:29 [plinss__]
plinss__ has joined #svg
23:01:30 [heycam]
DS: I'd like to be able to get at the computed values in the projection
23:02:13 [plinss__]
plinss__ has joined #svg
23:02:15 [heycam]
DS: another aspect of all of this is, a 'use' instance ... is this a rendering tree?
23:02:25 [heycam]
... if my reference thing is so big, and the instance is bigger...
23:02:30 [heycam]
TA: this is not rendering into a bitmap
23:02:34 [heycam]
... so it's before rasterisation
23:03:22 [heycam]
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, ...
23:03:29 [heycam]
TA: we should be able to do this use case, different colours
23:04:18 [heycam]
DS: i'd be worried about authors accidentally incurring performance penalty
23:04:28 [heycam]
TA: we shouldn't do the conversion from projected to real shadow implicitly
23:05:22 [heycam]
DG: do we really want a projected tree?
23:05:37 [heycam]
TA: I think we do want to be able to spam a lot of a single template without a big performance impact
23:06:02 [heycam]
JS: i'm not a layout expert, but I know that we have a pointer from all frames to their content node
23:06:18 [heycam]
... which we use a lot
23:06:18 [heycam]
... that breaks down in this case
23:06:31 [heycam]
... you can't point to the content node and say that's the thing it's resolving style against
23:06:59 [heycam]
... I agree we need this, it will be complicated to implement
23:07:26 [noriya]
noriya has joined #SVG
23:07:30 [heycam]
... 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
23:07:48 [heycam]
DG: webkit has the same problem
23:08:55 [heycam]
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
23:09:00 [heycam]
CM: for %age resolution?
23:09:23 [heycam]
TA: yes, and general sizing of user coordinates
23:09:23 [heycam]
... html is a lot more complex
23:09:31 [heycam]
... we could make these projection trees replaced elements, so they have a definite width/height
23:09:45 [heycam]
... they participate in outer pages layout, as opaque boxes, then figure out the size of the bounds, lay out the internals
23:09:50 [JanL]
when does the next discussion on svg/html5 <video> start?
23:09:58 [heycam]
very soon :)
23:10:11 [JanL]
23:10:11 [JanL]
just checking
23:10:54 [heycam]
JS: the hardest thing is the crazy svg thing, inheritance from two situations
23:12:01 [dglazkov]
we win!
23:12:28 [cyril]
23:12:31 [cyril]
scribe: Cyril
23:12:36 [cyril]
scribeNick: Cyril
23:13:10 [cyril]
Topic: SVG/HTML 5 video tag harmonization
23:14:00 [cyril]
JL: I'm with Ericsson, coming from the Web & TV IG
23:14:12 [cyril]
... on how the tv industry can influence W3C
23:14:31 [cyril]
... the question came up of how the SVG and HTML 5 video tag will merge
23:14:43 [cyril]
... I want to put the discussion on the floor
23:15:23 [a12u]
a12u has joined #svg
23:15:37 [cyril]
... the observation from the IG is that there would a lot of synergies if you could use the HTML 5 video tag in SVG
23:16:00 [cyril]
GP: or if we had a functionaly equivalent tag in SVG
23:16:16 [cyril]
JL: there's a lot of control in the HTML 5 video tag
23:16:20 [cyril]
... tracks, etc.
23:16:29 [cyril]
... being able to reuse that in SVG would be interesting
23:16:44 [aizu]
aizu has joined #svg
23:17:03 [cyril]
CC: is there a document/analysis of the difference ?
23:17:24 [cyril]
JL: I come the OpenIPTV forum and we identified several gaps, but HTML 5 has evolved since then
23:17:38 [cyril]
... all the bugs are almost fixed
23:17:51 [cyril]
GP: at this stage, there was no analysis made
23:18:01 [cyril]
... but is it the goal to merge in the long term ?
23:18:25 [cyril]
CS: my understanding is that the video tag in SVG and in HTML they don't use the same code base
23:19:03 [cyril]
... is there a fondamental reason why they wouldn't use the same code
23:19:13 [cyril]
ED: SVG does not use the CSS Box model
23:19:31 [cyril]
... the underlying code is already shared
23:20:48 [ed]
s/underlying code is already shared/underlying code (for loading and decoding video, putting it somewhere) is already mostly shared/
23:21:02 [cyril]
CC: in general the goal of the SVG WG is to align with HTML as much as possible
23:21:12 [cyril]
... having the same model, even if the syntax differ
23:21:32 [cyril]
JL: what is the next step ?
23:21:38 [cyril]
... do we need proposals
23:21:50 [cyril]
DS: the SVG video element only exists in SVG Tiny 1.2
23:22:14 [cyril]
... SVG 2.0 is not necessarily import all features from SVG Tiny 1.2
23:22:26 [cyril]
... there is no consensus in the group that all features of SVG T 1.2 are relevant in the HTML 5 world
23:22:51 [cyril]
... I believe it would be ideal if we had a video element that would be a super set of the HTML 5 video
23:22:53 [ed]
s/CSS Box model/CSS Box model for laying out svg elements/
23:23:14 [cyril]
... SVG Tiny 1.2 comes from SMIL and they are not in HTML 5 video
23:23:24 [cyril]
... the quwstion is are those desirable ?
23:23:43 [cyril]
... but I heard concerns that the animations and the video properties are not in the same stack
23:23:59 [cyril]
JL: often the video layer is done in hardware
23:24:25 [cyril]
... the question is should there be restriction on the way it can be manipulated
23:24:45 [cyril]
EF: speaking as an implementer, some of the things specified in HTML 5 is not implementable
23:24:58 [cyril]
... like a CSS Shader on a video on a mobile
23:25:03 [cyril]
... like multiple videos
23:26:18 [cyril]
DS: I dont think it's profitable to us to define a profile for mobiles when only hints are sufficient
23:26:31 [cyril]
... because the standards pace and the silicon pace are not the same
23:26:40 [cyril]
... but point taken
23:27:11 [cyril]
EF: simple cases of manipulation on desktop work but complex cases might not work
23:28:01 [cyril]
ED: I'm not sure it's possible to do the same
23:28:21 [cyril]
... for instance, the transformBehavior attribute is not in HTML 5
23:28:43 [cyril]
... I don't know if it's easy to have the HTML 5 video in SVG
23:29:11 [cyril]
DS: the fondamental question is the SMIL thing
23:29:45 [cyril]
CC: this is not a problem
23:29:56 [cyril]
... people are just scared of SMIL
23:30:15 [cyril]
... but the SMIL timing module when considering a single time container is very simple
23:30:39 [cyril]
GP: some the visual parts are not implementable on STB
23:30:47 [jcdufourd]
jcdufourd has joined #svg
23:30:49 [cyril]
... but people want would like multiple video tracks
23:30:56 [cyril]
... but people want would like multiple subtitle tracks
23:31:58 [cyril]
[JanL showing the comparison table from OIPF]
23:34:34 [cyril]
JL: we are mostly interested on video control use cases
23:35:11 [JanL]
23:35:25 [cyril]
CS: there are 2 issues: what are the different subsets/intersection of features; should that be directly addressed to reach a common understanding
23:35:41 [JanL]
annex L, page 360
23:36:02 [cyril]
... if we agree on the second question, we can then work on the other question
23:36:12 [cyril]
GP: is there a market for SVG video
23:36:26 [JanL]
this includes a table comparing SVG Tiny video element with OIPF embedded video objects defined in the spec
23:37:00 [cyril]
DS: we could have an SVG element behaving the same as the HTML 5 video element
23:37:18 [cyril]
TA: the video element of HTML 5 in the SVG namespace
23:37:41 [cyril]
JL: this sounds like a good idea
23:38:00 [cyril]
DS: we talked about HTML and SVG more tightly coupled in terms of parsing
23:38:50 [cyril]
... when parsing HTML + SVG, when the video element is encountered, what would be the namespace of the video element
23:40:23 [cyril]
... Is there any objection to having a video element in SVG namespace with the same characteristics as the video element ?
23:40:32 [cyril]
... would it be identical or a super set ?
23:40:51 [cyril]
... if we extend it, I would like to have them also applicable in HTML
23:40:57 [noriya]
noriya has joined #SVG
23:41:35 [cyril]
TA: we should be working toward a world where the SVG and HTML are the same language
23:42:29 [cyril]
RESOLUTION: SVG 2 will have a video element in SVG namespace with the same characteristics as the HTML 5 video element
23:42:55 [cyril]
RESOLUTION: SVG 2 will have an audio element in SVG namespace with the same characteristics as the HTML 5 audio element
23:43:26 [cyril]
... this includes the track, audio api, blah blah blah
23:43:56 [ed]
s/track/track, source/
23:44:47 [stakagi]
controls property?
23:45:12 [cyril]
ED: the UI controls might be different
23:45:18 [cyril]
DS: I would expect them to be the same
23:45:51 [cyril]
... you can always make your own SVG controls if you wish
23:46:30 [cyril]
EF: what would be the difference in using a foreignObject element ?
23:46:56 [cyril]
DS: you incur some performance problems with fO video that you would not have with native video
23:47:11 [cyril]
JY: we don't implement fO in IE
23:47:20 [cyril]
ED: the problems are at least in Opera
23:47:46 [cyril]
JL: how soon would this introduction take place
23:47:53 [cyril]
DS: 6 months maybe
23:48:34 [cyril]
ACTION: Doug to add HTML video/audio elements to SVG 2
23:48:34 [trackbot]
Created ACTION-3178 - Add HTML video/audio elements to SVG 2 [on Doug Schepers - due 2011-11-11].
23:49:34 [cyril]
DS: we could have an audio/video module that extends SVG 1.1
23:49:47 [cyril]
JL: that would be better in the timing perspective
23:49:59 [cyril]
... that would make a difference
23:50:12 [cyril]
DS: we could have a spec in LC by Q1 2012
23:51:27 [cyril]
RESOLUTION: We will have a module to SVG 1.1 to add audio/video elements with parity to HTML 5, given resources
23:54:18 [cyril]
RRSAgent, make minutes
23:54:18 [RRSAgent]
I have made the request to generate cyril
23:54:33 [shepazu]
trackbot, end telcon
23:54:33 [trackbot]
Zakim, list attendees
23:54:33 [Zakim]
sorry, trackbot, I don't know what conference this is
23:54:34 [trackbot]
RRSAgent, please draft minutes
23:54:34 [RRSAgent]
I have made the request to generate trackbot
23:54:35 [trackbot]
RRSAgent, bye
23:54:57 [Bert]
rrsagent, make logs public
23:55:30 [Bert]
rrsagent, make minutes
23:55:30 [RRSAgent]
I have made the request to generate Bert