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