16:23:24 RRSAgent has joined #svg 16:23:24 logging to http://www.w3.org/2011/10/27-svg-irc 16:23:26 RRSAgent, make logs public 16:23:26 Zakim has joined #svg 16:23:28 Zakim, this will be GA_SVGWG 16:23:28 I do not see a conference matching that name scheduled within the next hour, trackbot 16:23:29 Meeting: SVG Working Group Teleconference 16:23:29 Date: 27 October 2011 16:24:48 zakim, this will be SVG pre-TPAC F2F day 1 16:24:48 I do not see a conference matching that name scheduled within the next hour, ed 16:25:54 zakim, remind me in 8 hours about something 16:25:55 ok, ed 16:26:36 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda 16:26:52 chair: Erik 16:27:17 Scribe: Cameron 16:27:20 ScribeNick: heycam 16:29:08 Present: ED, CM, JF, ST, VH, CC 16:30:06 Present+ JY 16:34:35 Present+ DH 16:34:54 jyu3 has joined #svg 16:36:58 jen has joined #svg 16:37:08 Topic: Editing procedures for SVG2 16:40:41 ED: we discussed before about how to edit the spec and markup the spec, how to review 16:41:00 ... I think the idea with this topic here is to give a quick overview, and then to get jwatt to call in in the afternoon to say a bit more about the procedures 16:41:08 vhardy has joined #svg 16:41:10 ... as a starting point, everyone should know how to check out the specification 16:41:12 stakagi has joined #svg 16:41:14 ... we have a page on the wiki 16:41:34 ... Tav wrote on the mailing list, there's no page on the wiki about checking out the spec 16:41:42 s/checking out/writing/ 16:41:45 http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org 16:42:00 ... here is the page that shows how to get a clone of the SVG repository for SVG2 16:42:06 ... I think we have two separate repositories that you want to check out 16:42:11 ... the first is svg2, which contains the actual spec 16:42:13 dholbert has joined #svg 16:42:20 ... and then there's svg2-test, which should contain the test suite 16:42:28 ... and then there are some minor other repositories for working with the tools for building the spec 16:42:33 ... usually those are not actually important 16:42:41 ... I think it's enough to check out the test suite and svg2 repos 16:43:07 CM: I think you may need to check out the tools repo to build locally 16:43:14 ED: as a beginner's guide, the wiki page above is not perfect 16:43:21 ... but I just managed to get a checkout from that 16:43:35 ... that's what we have at the moment. I don't think there's a wiki page describing how to do review etc. 16:44:04 s/svg2-test/svg2-tests/ 16:45:32 CM: I think we should revisit the decision to review before commit 16:45:44 ... Erik and I are concerned that this is an obstacle for editing work getting done at the moment 16:45:53 ... there are two main areas of spec work that will happen 16:45:58 ... one is the existing spec text refactoring 16:46:04 ... and the other is adding text for the new features/proposals 16:46:11 ... I don't think the latter needs to wait on the former necessarily 16:46:25 ... it will be a little more work for the refactorer to reword the new features if they are written in the old spec style 16:46:31 ... but I don't think it will be a great problem 16:46:44 ... so I anyway think we should free up the process a bit so that people can get in and do the work 16:47:00 ED: currently the spec is just using some pink styling rules to indicate it hasn't been looked at yet 16:47:20 ... I'm not sure whether we would remove the pink if we aren't having review 16:47:32 ... so I think the wiki page should explain how to check out the spec, as well as clear editing instructions 16:47:40 ... but if we don't know the exact editing procedures we can't do the whole page 16:48:10 CM: I think one of us should just write up a page describing the desired procedure and we will agree on that 16:48:17 ACTION: Erik to write up a wiki page on SVG2 editing and procedure 16:48:17 Created ACTION-3152 - Write up a wiki page on SVG2 editing and procedure [on Erik Dahlström - due 2011-11-03]. 16:48:33 Topic: Requirements input for SVG2 16:48:38 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input 16:48:54 ED: I think the idea is to go through the entire list from top to bottom, for things we can agree on get resolutions for them 16:48:58 ... so that we can start doing the edits in the spec 16:49:06 ... we have a requirements document now being written up 16:49:14 http://dev.w3.org/SVG/profiles/2.0/reqs/publish/ 16:49:35 jun has joined #svg 16:50:00 cyril has joined #svg 16:52:15 CM: Erik and I will add to that document for the items we resolve on to include in SVG2, and publish that shortly after TPAC 16:52:32 CC: on the previous topic, we should discuss about which things remain in SVG2 16:52:36 ... for example, Filters should be taken out 16:52:42 ... maybe we should have actions for doing that 16:53:01 CM: I think the people doing general editing/refactoring of the spec should do that as a matter of course 16:53:20 ... I don't think we have resolutions on exactly which items have been split out form SVG2 16:54:00 [some discussion of whether Clipping/Masking should be part of the Filters spec] 16:54:10 ED: I think there was a decision on Seattle to move it to Filters 16:57:14 ACTION: Cyril to start a wiki page on SVG2 spec structure, showing which are split out into modules 16:57:15 Created ACTION-3153 - Start a wiki page on SVG2 spec structure, showing which are split out into modules [on Cyril Concolato - due 2011-11-03]. 16:57:38 ED: Let's start in the General category 16:57:43 ... first is "avoid backwards incompatible changes" 16:58:20 CM: I think Olaf's position is a bit extreme 16:58:30 ED: as a general guideline it's good to not break content going forward 16:58:44 CM: so "avoid" is ok, but not never 16:58:59 ED: probably don't need a resolution on this 16:59:07 ED: Next, generating shape data from raw data 16:59:12 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_shape_generation_from_raw_data 16:59:49 CC: it would be good to mention the backwards compat issue in the requirements document though 17:00:38 ACTION: Cameron to add a section to the Requirements document about general approaches 17:00:38 Created ACTION-3154 - Add a section to the Requirements document about general approaches [on Cameron McCormack - due 2011-11-03]. 17:01:46 ED: this is a big proposal, RDML from Dr O 17:02:18 ... I haven't read all of this, but I feel it's a bit too big to include in SVG at least 17:02:27 ... it feels like something that could at most be a module, or even apply to other things than SVG 17:03:29 CM: I think it's quite a big feature, and out of scope for SVG2 17:04:13 ... I think it's not clear that everyone would agree this is the right approach for mapping of data to DOMs in the web platform 17:04:33 ED: there are ways you can generate shapes from raw data right now, using XSLT for example 17:04:45 CC: to me it seems linked to sXBL 17:05:21 CM: the Web Components work is looking at script based solutions to begin with 17:05:27 ... and looking at declarative solutions later 17:05:35 ... if anything, it should be looked at as part of that effort 17:05:36 jen has joined #svg 17:05:41 RESOLUTION: We will not include RDML in SVG2. 17:05:59 ED: next, templating for controls and widgets 17:06:00 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets 17:06:31 ED: again I think that's something on top of, or outside of SVG 17:07:24 CM: again I think we should look to Web Components here 17:07:31 ... the work is gaining traction 17:07:38 ... we should ensure though that it solves our previous use cases for sXBL etc. 17:09:07 RESOLUTION: We will not include a templating mechanism in SVG2. 17:09:19 CM: Let's talk with Dmitri next week at TPAC about Web Components. 17:09:44 RRSAgent, pointer 17:09:44 See http://www.w3.org/2011/10/27-svg-irc#T17-09-44 17:09:59 ED: That was all from the general section 17:10:04 ... we don't have everything categorised yet 17:10:08 ... next area is Rendering Model 17:10:14 ... and next topic is z-index 17:10:16 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index 17:10:19 ... I believe we already resolved to include 17:10:33 ... so we don't need to discuss that 17:10:39 ... next, translucency 17:10:41 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Translucency 17:10:55 ... I didn't know exactly what was meant here 17:11:33 CM: I think opacity + blur filters is enough 17:12:08 CC: we don't have a lighting model 17:12:19 VH: from the description, I think we can do it with opacity and filters 17:13:00 RESOLUTION: We will not include translucency support, existing functionality is sufficient. 17:13:08 ED: next, flatten to image 17:13:09 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Flatten_to_image 17:13:25 ED: from the description I wasn't sure how this differed from the buffered-rendering property 17:13:29 ... seemed like the same thing to me 17:13:35 ... it's possible he meant to throw away the DOM tree as well 17:14:22 ... you can kind of lose scalability if you do that 17:14:34 CM: presumably you'd only use the feature where that is acceptable 17:14:41 ED: buffered-rendering does the same thing without throwing away the DOM 17:15:09 CM: if you are able to paint SVG to a canvas, then you could do that manually 17:15:12 ED: I think it's not a bad requirement 17:15:19 ... flattening to a raster is useful and necessary sometimes 17:15:31 ... I don't think we need to be very specific on how to solve it, but we should have it as a requirement 17:16:01 CM: buffered-rendering is a hint, so a bit different 17:16:09 ED: say you had a huge canvas you couldn't allocate 17:16:14 ... that can happen with buffered-rendering too 17:16:20 ... it doesn't mean anything changes in the rendering 17:16:28 CC: I don't hink it's related to buffered-rendering 17:16:41 ... if you put a group with 3 objects, one in the background, two next to each other 17:16:53 ... and put bufered-rendering on the group, you'll still see the object from the background 17:16:58 ED: not sure I follow 17:17:03 [Cyril writes on the board] 17:18:30 seems we skipped one, Cyril was talking about pixel rounding 17:18:43 VH: I agree that we he describes is similar 17:19:05 ... the thing he wants can be supported with libraries like canvg 17:19:13 ... you can render it into an offscreen canvas, then insert that canvas 17:19:51 ... there is work going on to fix the security issue with painting SVG content to canvas 17:19:55 DH: yes 17:20:13 CC: the point is not getting the bitmap, you sometimes want to keep a vector graphics representation in memory, but you want to get rid of the DOM 17:20:23 ED: that's what he's suggesting, not sure that's what you want always 17:20:35 DH: but this proposal is for a bitmap 17:20:53 ED: with buffered-rendering in Opera, updates will update the rendering, but not immediately 17:22:01 CC: I think it's a good requirement 17:22:06 ED: but we can discuss the solution later 17:22:48 RESOLUTION: We will add flatten to image as a requirement. 17:22:55 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Pixel_rounding_methods 17:22:58 ED: next, pixel rounding methods 17:23:14 VH: this is the same issue that Michael Bostock brought up at SVG Open 17:23:19 CC: well known problem 17:23:26 ED: I think we might have several issues/requests for this 17:23:29 ... don't think it's a new thing 17:23:46 CC: the thing I'm wondering about is, can a clever SVG implementation avoid this problem, or is it just incompatible with the rendering model? 17:23:51 .. let's say a dummy implementation makes 2 passes 17:24:04 ... first pass to determine the opacity of each pixel, the second pass it actually uses that to determine if the background is needed or not 17:24:07 ... from bg to fg 17:25:29 DH: what if you had opacity on the rectangles, maybe 99% 17:25:38 ED: Michael Bostock was mentioning FSAA 17:25:45 VH: the way people do that is supersampling on the pixels 17:25:58 ... in the case of the line, you realise you keep hitting the same subpixels and not creating the artifact 17:26:02 CC: but no implementations do that 17:26:24 VH: what you are suggesting is also quite complex 17:26:38 ... even if you have full covereage for the pixel, you have to figure out all the objects contributing to the opacity 17:26:40 ... it's not trivial 17:26:49 CC: I'm just wondering whether it's incompatible with the model 17:26:54 ... why don't we have a single browser doing it at the moment 17:27:02 ED: it solves some simple cases 17:27:06 VH: I think it's not there for historical cases 17:27:16 ... it's true that it's ugly in cases, but few people care about it 17:27:23 CC: I think it has been raised from the beginning 17:27:35 VH: but if you do a powerpoint presentation, or a flow diagram, most of those cases you'll never hit this 17:27:44 CC: I found this problem in flash to svg conersion 17:27:47 s/conersion/conversion/ 17:27:48 s/it solves some/the shape-rendering hint solves some of the/ 17:27:54 ... in Flash you can have many shapes that share a border 17:28:53 ED: I think what people want is sharp edges 17:29:09 VH: maybe a new rendering hint 17:30:51 DH: it seems like it would be hard in general 17:31:03 ... to do automatic pixel snapping and for that to do what you want 17:36:08 RESOLUTION: We will ensure there is a way to avoid getting seams on adjacent edges of rendered elements in SVG2. 17:54:18 thorton has joined #svg 17:55:29 ed, http://www.w3.org/TR/SVG2Reqs/ 17:57:40 ED: next section is Document Structure 17:57:41 Phone number? 17:57:44 ... namespace requirements cleanup 17:57:53 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Namespace_requirements_cleanup 17:58:05 Zakim, room for 3? 17:58:06 ok, ed; conference Team_(svg)17:58Z scheduled with code 26631 (CONF1) for 60 minutes until 1858Z 17:58:28 Zakim, code? 17:58:28 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 17:58:39 Thanks 17:58:57 Team_(svg)17:58Z has now started 17:59:04 +tbah 17:59:17 ok 18:01:16 + +1.650.693.aaaa 18:02:15 ED: we do have a resolution for xlink:href 18:02:23 ... we still have xml:id and other xlink-related things 18:02:28 ... not sure we have a resolution for that 18:03:02 RESOLUTION: We will reconsider use of namespaced things in SVG (xlink, xml:id, etc.). 18:04:45 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#.3Cuse.3E_cleanup 18:04:46 VH: browsers have started to do something re href="" too 18:04:50 ... so we should look at that 18:04:52 ED: next, use cleanup 18:05:37 CM: a bit vague 18:05:59 ... the one issue I can think of is the property inheritance into the shadow tree 18:07:04 CC: when you have a use element that includes a reference to a gradient, you need to duplicate the whole shadow tree each instance 18:08:44 ED: one part might be differences between implementations 18:08:47 ... ensuring things work the same 18:09:05 ... that could require having a second look at the current spec, seeing what's broken and what's differing 18:09:17 VH: I would suggest taking this as a need for a better referencing/cloning mechanism 18:09:34 ... I would accept this as a requirement, since it's a pain point for many people 18:11:01 RESOLUTION: We will require a feature that allows symbol reuse without requiring duplication of shadow trees in SVG2. 18:11:06 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Marker_cleanup 18:11:09 ED: next, marker cleanup 18:11:17 ... we have one resolution already, to add currentStrokePaint etc. 18:11:34 ... for inheriting colours into the marker 18:11:41 ... which seemed to be the thing most people were asking for 18:11:49 ... I think as a requirement, we should probably look a bit wider 18:11:53 ... on how to improve markers 18:12:30 RESOLUTION: We will improve markers for SVG2. 18:12:34 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shadow_tree_cleanup 18:12:38 ED: next, shadow tree cleanup 18:12:44 ... not sure if that's different from use cleanup 18:12:52 ... I think that could be the same thing 18:13:25 ... next one is "improve the DOM" 18:13:51 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM 18:14:04 ... we have a bunch of different proposals 18:14:11 ... I've collected some of them as subpoints of this item 18:14:14 ... so we could resolve on those 18:14:17 ... it's more contained, simplified 18:14:32 ... first of those is "improve the DOM for SVG Animation" 18:14:32 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM_for_SVG_Animation 18:14:34 VH: yes 18:14:52 ED: I proposed a simple API to grab the current motion animation 18:14:57 ... that's been asked for a number of times 18:15:48 DH: supposing the element itself is transformed, does this take into account all of the element's transforms? 18:15:54 ED: just the transform for the motion animation 18:16:07 CC: we don't have a microdom equivalent for that? 18:16:09 ED: don't think so 18:17:13 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AnimateMotion_DOM_API 18:18:25 RESOLUTION: We will expose animateMotion values in the SVG DOM in SVG2. 18:18:46 ED: next I think we have a resolution for, at least there's an action to do it, that's "make the SVG list interfaces a bit more like arrays" 18:18:52 ... two implementations already do this 18:18:59 ... I think I have the action to add that 18:19:09 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM 18:19:13 ... next is "make it easier to read/write attributes in the DOM" 18:22:44 [discussion about issues with SVGAnimatedLength] 18:23:01 RESOLUTION: We will make it easier to read and write to attributes in the SVG DOM in SVG2. 18:23:20 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_SVG_path_DOM 18:23:23 ED: next is improve the SVG path DOM 18:23:51 VH: agree 18:24:04 ED: not entirely clear what to do, but the SVGPathSegList interface is horrible 18:24:20 VH: maybe the requirement could be to make a general useful path api, maybe not just for svg, but could draw into a canvas or something 18:24:54 +1 to shared graphics API 18:25:23 VH: do desktop browser implement any 1.2T dom? 18:25:26 ED: just Opera I think 18:25:35 ... for path api, I like the one in Tiny more 18:25:40 ... it's not perfect, but better 18:26:35 RESOLUTION: We will improve the SVG path DOM APIs in SVG2. 18:27:04 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A_way_to_access_.28presentational.29_property_values_easily 18:27:06 ED: next, way to access presentational property values easily 18:27:11 CC: getPresentationTrait? 18:27:20 ED: similar, Jeff was saying that it's hard to get the colour value of some fill or stroke 18:27:24 ... if you have to use the CSSOM, it's pretty bad 18:27:30 ... maybe even more dots than the SVG DOM 18:27:35 ... and it's not usually very well implemented 18:27:50 CM: is this just an issue for the CSSOM spec? 18:27:59 ED: that, or we could address it with a trait access interface 18:28:14 ... I'm not 100% sure that CSSOM will allow accessing base and animated values 18:29:28 RESOLUTION: We will coordinate with other WGs to ensure improved property value access to SVG properties in SVG2. 18:29:49 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_possible_to_get_the_bounding_box_of_an_element_in_a_particular_coordinate_system 18:29:52 ED: next, make it possible to get a bbox of an element in a particular coordinate system 18:29:56 ... this is a pretty detailed requirement 18:30:03 ... I think we should probably look at a few different things related to this 18:30:18 ... I know we had in 1.2F reqs, the requirement to get bounding boxes with strokes, markers, etc. 18:30:27 ... I think that's we something we definitely should have in SVG2 18:30:33 ... getting hte bounding box in different coordinate systems 18:30:45 ... what coordinate systems? 18:30:50 ... we have getScreenBBox 18:31:05 VH: is there a proposal for how this would be done? 18:31:39 ... if you could have a target element parameter to getBBox, that would be handy 18:34:01 CM: getBoundingClientRect was suggested as a way to include stroke 18:34:10 JY: that doesn't work if the element is out of the viewport, though, I found 18:34:28 RESOLUTION: We will improve bounding box method APIs in SVG2. 18:35:49 ED: a couple more big things about improving the DOM, haven't been split into subcategories 18:35:52 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM 18:37:52 RESOLUTION: We will generally improve the SVG DOM for SVG2 (specific proposals to be resolved on later). 18:38:05 ACTION: Cameron to add Improving the SVG DOM as a design approach/direction to the Reqs document 18:38:05 Created ACTION-3155 - Add Improving the SVG DOM as a design approach/direction to the Reqs document [on Cameron McCormack - due 2011-11-03]. 18:38:15 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Automatic_fetch.2Fdiscard_of_subtrees 18:38:22 ED: next is "automatic fetch/discard of subtrees" 18:38:27 CC: Is that discard element from 1.2T? 18:40:49 CM: sounds more like tiling, or automatic resource fetching from the server according to zooming/panning 18:40:54 ED: let's wait until Chris is here for that one 18:41:03 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Additional_generic_element 18:41:04 ED: next is "additional generic element" 18:41:34 ... in 1.2T we have role/rel/rev/etc. 18:41:42 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#role.2C_rel.2C_rev.2C_about.2C_content.2C_datatype.2C_property.2C_resource.2C_typeof 18:43:21 CC: not sure what he means with "structure" content 18:43:26 ED: you could use html content as structured elements in there 18:45:08 RESOLUTION: We will not add a new semanticless SVG element to hold role/rev/etc. attributes to SVG2. 18:45:13 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_viewBox_on_image 18:45:49 ED: next, "allow viewBox on image" 18:45:53 why not? 18:46:08 CC: they can use rdf elements for that 18:46:36 might be useful to add RDFa and microdata attributes 18:46:45 shepazu, that's a different issue which we haven't got to yet though 18:46:48 oh, sorry, no new element… that's fine 18:47:05 ED: for viewBox on image, don't we already allow that? 18:47:10 DH: we allow preserveAspectRatio, but not viewBox 18:47:19 ... for SVG images, it takes the viewBox from the image itself 18:47:37 .. preserveAspectRatio="defer" exists to mean take the pAR value from the referenced image 18:47:43 ED: I think it would be useful to be able to select a part of any image 18:47:52 DH: there's functionality for this in CSS3 Images 18:48:06 ... I guess this would be in xlink:href="" on though 18:48:13 ... the CSS way is to include it in the url fragment 18:48:22 ... I worry about having different ways to do this depending on the context 18:48:30 ... we do already support viewBox for a number of other things, though 18:48:38 ... so this would just override the viewBox from the SVG image if it has its own? 18:48:44 ... or does it refer to a subregion of what's displayed 18:49:10 ED: I think in some cases you want percentages, lengths... viewBox doesn't give that functionality 18:49:42 CC: the viewBox uses the coordinate system of the parent document, which might not be consistent with the child document 18:49:45 DH: I don't think it would in this case 18:51:39 RESOLUTION: We will have a method for to select a part of an image to display, maybe by allowing viewBox on it. 18:52:24 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Auto-sized_image 18:52:26 ED: next, "auto sized image" 18:52:39 ... I think being able to leave off width/height and taking it from the image you're loading 18:52:55 DH: would that just resolve to 0 for SVG images with %age size? 18:52:57 ED: undecided 18:53:14 ... Chris says maybe, because you don't always want to scale the image 18:54:39 CM: is there a way to get natural width/height of an image in SVG? 18:54:43 ED: no, not like in HTML 18:56:04 RESOLUTION: We will allow auto-sized images in SVG2. 18:56:20 ED: next, accessibility 18:56:22 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Accessibility 18:56:34 ED: more of a general thing 18:59:03 CM: not sure what accepting "accessibility" as a requirement exactly entails 18:59:14 ... we do want to improve on the title/desc element only situation 18:59:18 ED: we have aria we will include, too 19:01:00 RESOLUTION: We will keep accessibility in mind when designing new features, and improve existing features where we can, in SVG2. 19:01:24 ED: next, level of detail control 19:01:25 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control 19:02:17 -tbah 19:03:30 http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming 19:05:22 CC: is that proposal targetting 1.2T? 19:05:49 ST: it isn't designed to be limited to just 1.2T 19:05:55 ED: I think level of detail is something I would like 19:06:10 definition of view scale is a bit unsteadily 19:06:40 ED: if I was doing something like this, I would want to try to keep it as a CSS property 19:06:45 ... or presentation attribute 19:06:56 CM: to say valid at certain zoom level? 19:06:57 ED: yes 19:07:07 ... would be nice to write style sheets where certain things get hidden depending on the zoom level 19:07:18 disconnecting the lone participant, +1.650.693.aaaa, in Team_(svg)17:58Z 19:07:21 Team_(svg)17:58Z has ended 19:07:21 Attendees were tbah, +1.650.693.aaaa 19:07:31 Conference call timed out... but I think I'll call it a night so don't bother restarting. 19:07:40 tbah, ok, thanks for calling in! 19:11:14 CM: Let's talk with Chris about that one when he is in 19:14:17 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups 19:14:19 ED: next, display of InkML trace groups 19:15:10 ED: he saying that if you draw it with SVG, you have to add lots of DOM nodes 19:15:12 ... and it gets heavy 19:16:32 CC: he says it would be fantastic to be able to draw inkml trace groups 19:16:41 ... but he is first looking for solving the earlier issues that prevent him using svg 19:17:54 ED: it's hard to say without having some example 19:17:59 CC: there are two points here 19:18:09 ... one is "bitmap accumulation" 19:18:25 ... "the two reason i continue to use canvas svg ... is bitmap accumulation and n-dimensional trace groups" 19:19:56 ACTION: Cameron to contact Charles about http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to clarify with examples the "two areas most-lacking in SVG" 19:19:56 Created ACTION-3156 - Contact Charles about http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to clarify with examples the "two areas most-lacking in SVG" [on Cameron McCormack - due 2011-11-03]. 19:20:23 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Placeholder_graphics_for_unresolved_images 19:20:42 ED: next, placeholder graphics for unresolved images 19:20:51 CC: if the link is broken you want to display something, I think that is a reasonable requirement 19:21:57 CM: does switch an eRR work? 19:21:58 CC: no 19:22:18 s/an/and/ 19:23:13 thorton has joined #svg 19:24:25 VH: I would do the same thing that HTML does 19:25:38 JY: I think customising is a bit much 19:25:54 DH: in standards mode, HTML images do not render placeholder images any more 19:26:00 ... but anyway you can't customise them 19:26:17 ... I think unless there's a huge desire from authors, it might be less useful 19:28:39 s/mode/mode in Gecko/ 19:28:47 ED: I think it makes sense to be the same on HTML 19:28:50 s/on/as/ 19:29:38 CL: people testing their content might want different behaviour to the end user 19:29:41 DH: webkit and opera both render placeholder images in html, even in non-quirks mode 19:31:46 http://www.w3.org/2009/05/20-svg-minutes.html#item05 19:38:02 JY: I'd only support it if it applied HTML content as well 19:38:26 CL: we could defer it until either of those actions gets done, and specific proposals come up, but for the moment we are not accepting it as an SVG2 requirement 19:38:51 RESOLUTION: We will not have a feature to provide broken image fallback content, unless specific proposals are worked on further. 19:39:21 The ISSUE-2040 and the two actions ACTION-2567 and ACTION-2568 on jwatt and chrisl 19:48:24 -- break for lunch -- 20:30:00 Zakim, room for 2? 20:30:01 ok, heycam; conference Team_(svg)20:30Z scheduled with code 26631 (CONF1) for 60 minutes until 2130Z 20:30:18 Zakim, code? 20:30:18 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 20:30:42 Team_(svg)20:30Z has now started 20:30:49 + +1.650.693.aaaa 20:31:38 +[IPcaller] 20:31:41 - +1.650.693.aaaa 20:31:43 + +1.650.693.aaaa 20:31:53 ChrisL has joined #svg 20:33:00 Scribe: Cyril Concolato 20:33:05 ScribeNick: Cyril 20:33:12 Topic; SVG Glyphs in OpenType fonts 20:33:39 Topic: Hinting or multi-resolution switching, and other issues with SVG glyphs in OpenType fonts 20:33:41 Zakim, [IP is roc 20:33:41 +roc; got it 20:34:01 CM: Sairus is here and wants to contribute in this area 20:34:45 SP: various use cases: tablet PC magazines, emoji ... 20:34:53 ... we would like to have color and animations 20:35:03 ... SVG Fonts seem on a deprecated path 20:35:20 ... bringing open type would be an advantage 20:35:26 ... there is a couple of issues 20:35:39 CL: I've seen several proposals 20:35:58 adam twardoch 20:36:16 SP: Adam Twardoch brought up on the opnetype list a proposal where an SVG font would be in an Open Type font 20:36:38 [SP explaining OpenType / OFF on the board] 20:36:57 ... cmap provides unicode - glyph id association 20:37:10 http://lists.w3.org/Archives/Public/www-style/2011Jun/0636.html 20:37:11 ... TrueType had various glyf tables 20:37:44 Si Daniels (Microsoft) http://www.typecon.com/archives/646 OpenType, in Living Color? 20:37:52 ... Some said we like some tables in OpenType, but we don't like OpenType outlines 20:38:16 ... that's why there is CFF (Compact Font Format) outlines 20:38:48 ... you have truetype or CFF rasterizer 20:39:08 ... we would like to have a 3rd type of outlines: SVG, but everything else would be the same 20:39:16 'SVG ' 20:39:41 ... the content of the outline could be an SVG element 20:40:03 ... another proposal would be to have a full document per glyph 20:40:32 ... another proposal, is having a single document for all glyphs but a glyph referenced inside 20:40:56 (how about ?) 20:41:04 ... we would have to make clear the correspondence between glyph id and SVG id 20:41:28 ... that 3rd option has several advantages: single timeline if there is an animation for hte glyphs 20:41:49 ... the first option (SVG ) has some redundancy (encoding ...) 20:41:57 ... like CFF has problems 20:42:49 ... I want to discuss a model where a single SVG document is needed 20:42:59 ... I want to discuss security 20:43:24 ... secure animation mode (no arbitrary download, scripting ...) 20:43:44 CL: you don't need to get rid of scripting to insure security 20:43:46 (no external reerences, etc.) 20:44:08 (I'm happy to add this use case to SVG Integration spec) 20:44:15 ... you can say scripting has no access to the DOM, but is constrained to access to the font it's embedded in 20:45:21 SP: allowing scripting, how could someone argue that it would be a bad thing 20:45:55 CL: you could always have DoS attack, ... but if the script is able to access the document there is a proble; 20:46:10 (in short, we can add whatever "mode" or feature restriction we need, and which is technically possible, to SVG Integration) 20:46:14 ... if you sandbox the script, if it's self contained, there would be less problem 20:46:47 SP: one item would be defining the restriction mode we want 20:47:04 CL: I prefer that to restricting to no use of script because it might be useful 20:47:20 ROC: each instance of the font will have its own script context 20:47:47 (we could simply add security errors to dangerous methods in this context) 20:47:56 ... the other issue, SVG as images has some issue with regards to loading of resources 20:48:23 ... we would want to impose the same restrictions on font as on images for simplicity 20:48:30 CL: I understand that point but disagree 20:48:44 ... font designers want to use that feature (script) 20:48:48 (adaptive connections and such?) 20:48:56 ... it cuts off too many uses cases 20:49:08 SP: so far fonts have been predictible 20:49:14 (I'd love to see the scripted font use cases) 20:49:19 ... today you can construct malicious fonts 20:49:39 ... our current font formats are not beyond security problems 20:50:10 ROC: what are the real use cases ? 20:50:26 (I expect that randomness in glyph distortion would be nice) 20:50:37 CL: font designers talked about randomization 20:50:55 ... I' m happy to go back to them and ask specific use cases 20:51:10 ROC: we could have a version 1 without scripting 20:51:18 ... and then a v2 with scripting 20:51:34 ... if you rely on script first and realize it's a bad idea, you cannot go back 20:52:00 PS: we could see how fast such fonts are used in workflows 20:52:56 CL: we will already have a problem with IE not supporting SVG animations, but if we cut scripting out, we'll only be left with colors and glyphs 20:53:19 ... scripting is a way to do animation cross-browser 20:53:36 ED: if you don't have scripting, you cannot do feature detection for certain browsers 20:54:42 ROC; it's given that the script in the font should not access the DOM that's using the font 20:55:20 ... we would have also to decide about each API to see if it's wanted or not, that's a huge work 20:55:47 CL: the answer to most question is no, we would only make a positive (short) list of allowed API 20:56:26 ... I'm not saying it's free or easy, I'm saying it's valuable 20:57:21 ... there are font technology allowing arbitrary to run python, but not in browsers 20:58:00 ROC: we can get things out quickly if we don't put script in in the first place 20:58:29 SP: number 3 option (one single SVG document) 20:58:55 ... Apple has invented the 'sbix' table (not yet published) contains images for color but non-animated emoji 20:58:59 ... this is a very big table 20:59:10 ... it's not scalable 20:59:34 ... Apple thinks colored emoji is fine, but they don't see the need for animations 20:59:59 ... Adobe definitely wants scalability and animations 21:00:47 ... we'd like not to invent an additional table for hand tuned animated/colored bitmaps 21:01:09 ... making SVG look good at small font size would be a better solution 21:01:19 ... like hinting 21:01:42 ... it should look good in text messages (circles, smiley faces with eyes) 21:01:59 DH: non scaling strokes could help font that 21:02:13 CL: it's in SVG Tiny 1.2 and will be in SVG 2 21:03:25 PS: the stroke won't necessarily snap 21:04:10 CL: at one point, we looked at Type 1 for hinting of SVG fonts 21:04:21 ... we did not feel that it applied well to SVG 21:04:57 ... because of slanting, orientation and fixed font size, not at arbitrary rotation, scale ... 21:05:33 PS: a Type 1 type model of hinting could be invented for SVG, but the animation part would have to be dealt with 21:06:32 SP: smiley face should be snapped on pixels, but when it moves you couldn't do snapping the same way 21:06:55 ... maybe it's impossible 21:07:37 CL: we could have two modes: disable pixel snapping when it's moving 21:07:44 CM: we have the rendering properties 21:07:48 ... for that 21:08:06 ... that's what you want to use for the animation 21:08:31 ... geometricPrecision 21:09:16 CL: hinting is turned off on some platforms (MacOS) 21:09:30 ... on windows vertical or horizontal is off too 21:09:52 ... the emphasis on hinting seems to be shifting 21:10:32 ... the range of device resolutions is diverging 21:10:44 ... so the 'sbix' solution cannot be future-proof 21:11:30 CM: we also discussed something similar to CSS media queries 21:11:40 ... in the past, but it did not go in the spec 21:12:46 ... but you could use a raster image instead of SVG for small sizes 21:14:05 CL: [explaining optical scaling] 21:15:06 CM: if SVG did not put hinting or features for small size, how useful would SVG be ? 21:15:16 PS: hard to answer 21:16:03 ... I could see lots of use cases for SVG at large ppm 21:16:26 ... especially with animations (magazines, ePub) 21:17:40 ... I wanted to check about option #3: a single SVG document 21:18:00 CM: the svg document can be quite big 21:18:23 ... but the font engine would not be required to load all of it 21:18:36 CL: unless glyphs share resources 21:19:31 CM: I was wondering if we could combine option 1 & 2, have 1 document per glyph but 21:19:59 s/1 & 2/2 & 3/ 21:20:28 ... being able to have a shared document 21:21:42 CL: we could construct an on-the-fly SVG document based on OpenType tables 21:22:03 PS: the element has problems 21:22:35 CC: this would require a pre-process to construct the document 21:22:45 PS: the OpenType engine would do that, yes 21:23:13 CM: that's an issue between the OpenType engine and the SVG engine 21:23:51 PS: in Flash, we try to memory map the whole file if the device has enough memory 21:24:05 ... and the CFF engine does not need a lot of memory 21:24:32 ... for ex a full Japanese font on an Android device 21:24:56 ... I don't know if SVG renderer need a copy of the SVG 21:25:16 CM: most of the time, the SVG engine gets SVG from the network by chunks 21:26:05 PS: we don't want to create documents for each key stroke 21:26:55 CM: you know the initial set of glyphs required (possibly an empty SVG document running in the background) 21:27:13 ... as more glyphs are required, you parse the glyph outlines and you insert them in the document 21:27:29 CC: you would need to delete some of them 21:27:38 CM: it could be an implementation issue 21:28:00 PS: is such interface possible between an SVG engine and an OT engine 21:28:19 CM: you probably want to use an off-the-shelf engine 21:28:48 ROC: if the child can be inserted in any order, you can use CSS style selectors 21:30:03 ROC: with CSS selectors, the exact order that the runtime insertions of the elements can have an effect 21:30:16 ROC: even without script 21:30:36 ROC: I think an SVG engine could be used 21:32:31 CM: when you have a large font, you need to have all glyphs in the document, that would consume a lot of memory 21:33:03 ... one thing is the actual text and the other is the actual DOM element in memory 21:33:20 ROC: we could use display:none 21:34:31 CM: is it necessary for these glyph elements to be in the DOM ? 21:36:11 ROC: could insert only a single glyph at a time, only one exists in the document at once; that would resolve css selector predictability issues 21:36:20 ROC: but would screw up animation timelines 21:37:24 CL: what about the range of characters that the SVG outlines 21:37:39 PS: you could indicate to which characters the SVG glyphs correspond 21:38:34 ... today there's is nothing preventing from mixing CFF and TT outlines in one font 21:39:01 ... we could have a new signature for OT fonts with SVG outlines 21:39:16 ... or define a fallback when SVG fonts cannot be used 21:40:22 CM: coming back to the issue of the big table 21:40:35 ... how big a problem would be the memory problem 21:40:55 PS: hard to say 21:42:06 ED: what if you reference the same font with text inside the font? 21:42:18 CL: we should disable that and other things, such as foreignObject HTML 21:42:46 PS: what would be the big picture of someone wanting to implement that ? 21:42:56 ... in ebook reader and so on 21:43:06 ... out of the context of browsers 21:44:13 CC: at SVG Open, we learned that ebook readers actually use browsers 21:44:22 .. at least 4 of them 21:45:12 CM: if we define the format such that glyph are SVG graphics, internally the browsers could use an API to request the graphics from a global font document 21:46:10 CL: there is a need for font expertise and SVG expertise, why not use a Community ? 21:47:24 s/Community/Community Group/ 21:47:58 http://www.w3.org/community/ 21:47:58 CM: in terms of interface between the 2 engines, Gecko and Webkit will expose the data a little bit differently but in general they will render the document in the same way 21:48:22 CM: the state of the document in memory is not exactly what you want to render 21:48:52 CM: you could do: grab that element in that document and draw it somewhere else 21:51:04 CC: you could use the import node API 21:51:14 ED: you could also switch on the glyph id 21:51:23 http://www.w3.org/community/groups/proposed/#svgopentype 21:57:04 ED: another option could be to use nested SVG documents: one svg document per glyph in a bigger SVG document 21:59:00 s/you could also switch on the glyph id/the idea for selecting only one element (based on glyph id) inside the top svg is very similar to how processing works/ 22:02:11 PS: what about when animated fonts need to be printed ? 22:02:33 ED: you can use the snapshotTime attribute to indicate what is the preferable printed version of the glyph 22:03:20 CM: but it depends on the SVG rendering engine and it's API 22:03:28 s/it's/its/ 22:05:13 -roc 22:05:17 - +1.650.693.aaaa 22:05:18 Team_(svg)20:30Z has ended 22:05:20 Attendees were +1.650.693.aaaa, [IPcaller], roc 22:05:25 -- coffeebreak -- 22:25:11 Topic: Text-to-path API 22:25:49 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_to_path_API 22:26:10 CL: what's it's for? do you want it to be hinted? 22:27:41 CM: having unhinted text would be okay. using text-rendering would ensure normal text is fine 22:28:51 cyril has joined #svg 22:30:12 (group is created,join here http://www.w3.org/community/groups/#svgopentype ) 22:31:30 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Add_a_DOM_method_for_getting_glyph_path_data 22:33:32 rrsagent, make minutes 22:33:32 I have made the request to generate http://www.w3.org/2011/10/27-svg-minutes.html ChrisL 22:33:48 ED: I don't think anyone would use it, I think they would just get the string anyway. What would you do with the path anyway? 22:34:19 CM: Rik suggested an alternative API where you get a sequence of glyph paths and positions 22:35:19 CM: you don't want a single position and glyph because it might be rotated, etc. it's more of a final rendered shape that you want to get 22:35:58 CM: you definitely want to be able to get the result of the engine with transforms since it's otherwise difficult to do 22:37:05 s/would use it/would use the SVGPathSegList/ 22:38:43 ED: I would prefer a simple API on this one. 22:39:34 CM: I would be okay with removing the decorations stuff. If you have the geometry, you can do whatever you want with it anyway 22:41:19 ED: Just return the path data, gives you an array of glyph shapes 22:43:34 DH: Either putting the methods on the text node or passing in the text node makes sense. Either way you need access to the text node and its style context 22:44:04 ED: What positions was Rik talking about? 22:44:50 CM: Using that position as placing the baseline and left edge of the glyph but it only handles horizontal text and doesn't account for rotation. It might be simpler just to have that position encoded in the path 22:47:24 DH: What happens if you pass in a text node not in the document? 22:48:06 CM: What happens if you have a style element disconnected to the document, then have a disconnected text node reference that style? ED: it's undefined 22:49:04 Alex has joined #svg 22:50:51 ED: The most important part is getting the outlines. CM: We can leave the decorations off. 22:52:13 CM: Should dx, dy be encoded in the path itself? Or should it be returned separately (eg. so that every glyph starts at 0,0 and then has x, yoffsets defined elsewhere) 22:52:24 CM: What's more useful for authors? 22:52:50 This API needs to work font agnostic - i.e. if I'm an SVG Full font implementation and I ask for the paths, what do I get? P.S. Is there a dial-in? 22:53:26 ChrisL2 has joined #svg 22:53:46 ChrisL has joined #svg 22:53:51 Alex, hi, we can set the bridge up 22:53:57 Zakim, room for 3? 22:53:58 ok, heycam; conference Team_(svg)22:53Z scheduled with code 26631 (CONF1) for 60 minutes until 2353Z 22:54:02 Zakim, code? 22:54:02 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 22:54:13 Thanks 22:55:57 Team_(svg)22:53Z has now started 22:56:04 + +1.650.693.aaaa 22:58:11 CM: When I originally thought about this, it was with text on a path. And then including rotation and position information separately is not so easy 22:58:37 +[IPcaller] 22:58:52 CM: As a convenience, return the point that is the baseline left edge of the glyph 22:59:12 DH: What if we promise that the first command is a move command and then the author can strip that off if need be? 22:59:14 Zakim, [IP is AD 22:59:15 +AD; got it 23:01:26 AD: If you have full fonts, you'll lose a lot of information if you just get back one outline per glyph CM: Type with plain outline or SVG DOM subtree 23:01:55 CM: Should stroking of the text be returned as well? 23:04:22 AD: Emoji fonts, for example, gradients and everything are part of the glyph definition. You may want to get the whole dom tree back and not just the path 23:07:31 CM: disconnected elements from the tree? for simplicity, it will only work on elements within the tree 23:07:44 ED: you can always use visibility:hidden as a workaround. DH: or in the element 23:08:06 CM: Decorations are not being included in the returned paths 23:08:12 CM: Return unhinted outlines 23:17:20 CM: Positions? Will look at not including offsets and rotation in the path data 23:19:53 CM: Paths need to render the same regardless of fill-mode 23:22:59 CM: Some fonts are restricted and don't let you get their outlines. API should check for font permissions. This seems like a more general fonts thing, not just for this API CL: Browser should ignore those bits, since most fonts on the web are linked and not embedded. CM: The difference is that with this API, you can get the outlines of a user's locally installed fonts 23:23:45 CM: Maybe you could restrict it to only allow @font-face fonts. 23:23:59 CM: Font permissions should be ignored in the text-to-path API 23:24:10 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Spec_structure 23:24:32 Topic: SVG2 spec structure 23:26:43 cyril, http://dev.w3.org/csswg/css3-transforms/ 23:56:48 Scribe: Cameron 23:56:52 ScribeNick: heycam 23:56:54 Topic: Back to requirements list 23:56:56 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Automatic_fetch.2Fdiscard_of_subtrees 23:57:06 ED: automatic fetch/discard of subtrees 23:57:53 AD: this came out of the tiling/mapping work 23:58:12 ... when you pan the UA, it works out if the animation elements that are referenced in the visible viewport, and it pulls in content in demand 23:58:16 ... and it blows ones out of view away 23:58:26 ... gives you the ability to have a map of the world, zooming in/out, subtrees on demand 23:58:37 ... without any script control 23:58:55 CM: are there more use cases than maps? 23:59:04 AD: the silverlight deep zoom, a 100 megapixel image for example 23:59:08 ... you can pull the tiles in and out 23:59:18 ... multiresolution images