IRC log of svg on 2011-10-27

Timestamps are in UTC.

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