- From: Chris Lilley <chris@w3.org>
- Date: Fri, 28 Oct 2011 06:23:12 +0200
- To: public-svg-wg@w3.org
Hello,
Minutes (morning and afternoon merged) at
http://www.w3.org/2011/10/27-svg-minutes.html
and below as text for machine intelligences
SVG Working Group Teleconference
27 Oct 2011
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2011/10/27-svg-irc
Attendees
Present
ED, CM, JF, ST, VH, CC, JY, DH, CL, DS, AD, Sairus Patel
Regrets
Chair
Erik, Cam
Scribe
Cameron, Cyril Concolato, Erik
Contents
* [4]Topics
1. [5]Editing procedures for SVG2
2. [6]Requirements input for SVG2
3. [7]Hinting or multi-resolution switching, and other issues
with SVG glyphs in OpenType fonts
4. [8]Text-to-path API
5. [9]Requirements input for SVG2 (continued)
* [10]Summary of Action Items
_________________________________________________________
<trackbot> Date: 27 October 2011
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Editing procedures for SVG2
ED: we discussed before about how to edit the spec and markup the
spec, how to review
... 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
... as a starting point, everyone should know how to check out the
specification
... we have a page on the wiki
... Tav wrote on the mailing list, there's no page on the wiki about
writing the spec
<ed> [11]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
[11] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
ED: here is the page that shows how to get a clone of the SVG
repository for SVG2
... I think we have two separate repositories that you want to check
out
... the first is svg2, which contains the actual spec
... and then there's svg2-tests, which should contain the test suite
... and then there are some minor other repositories for working
with the tools for building the spec
... usually those are not actually important
... I think it's enough to check out the test suite and svg2 repos
CM: I think you may need to check out the tools repo to build
locally
ED: as a beginner's guide, the wiki page above is not perfect
... but I just managed to get a checkout from that
... that's what we have at the moment. I don't think there's a wiki
page describing how to do review etc.
CM: I think we should revisit the decision to review before commit
... Erik and I are concerned that this is an obstacle for editing
work getting done at the moment
... there are two main areas of spec work that will happen
... one is the existing spec text refactoring
... and the other is adding text for the new features/proposals
... I don't think the latter needs to wait on the former necessarily
... it will be a little more work for the refactorer to reword the
new features if they are written in the old spec style
... but I don't think it will be a great problem
... so I anyway think we should free up the process a bit so that
people can get in and do the work
ED: currently the spec is just using some pink styling rules to
indicate it hasn't been looked at yet
... I'm not sure whether we would remove the pink if we aren't
having review
... so I think the wiki page should explain how to check out the
spec, as well as clear editing instructions
... but if we don't know the exact editing procedures we can't do
the whole page
CM: I think one of us should just write up a page describing the
desired procedure and we will agree on that
<scribe> ACTION: Erik to write up a wiki page on SVG2 editing and
procedure [recorded in
[12]http://www.w3.org/2011/10/27-svg-minutes.html#action01]
<trackbot> Created ACTION-3152 - Write up a wiki page on SVG2
editing and procedure [on Erik Dahlström - due 2011-11-03].
Requirements input for SVG2
<ed>
[13]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
[13] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
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
... so that we can start doing the edits in the spec
... we have a requirements document now being written up
[14]http://dev.w3.org/SVG/profiles/2.0/reqs/publish/
[14] http://dev.w3.org/SVG/profiles/2.0/reqs/publish/
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
CC: on the previous topic, we should discuss about which things
remain in SVG2
... for example, Filters should be taken out
... maybe we should have actions for doing that
CM: I think the people doing general editing/refactoring of the spec
should do that as a matter of course
... I don't think we have resolutions on exactly which items have
been split out form SVG2
[some discussion of whether Clipping/Masking should be part of the
Filters spec]
ED: I think there was a decision on Seattle to move it to Filters
<scribe> ACTION: Cyril to start a wiki page on SVG2 spec structure,
showing which are split out into modules [recorded in
[15]http://www.w3.org/2011/10/27-svg-minutes.html#action02]
<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].
ED: Let's start in the General category
... first is "avoid backwards incompatible changes"
CM: I think Olaf's position is a bit extreme
ED: as a general guideline it's good to not break content going
forward
CM: so "avoid" is ok, but not never
ED: probably don't need a resolution on this
... Next, generating shape data from raw data
<ed>
[16]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
eclarative_shape_generation_from_raw_data
[16] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_shape_generation_from_raw_data
CC: it would be good to mention the backwards compat issue in the
requirements document though
<scribe> ACTION: Cameron to add a section to the Requirements
document about general approaches [recorded in
[17]http://www.w3.org/2011/10/27-svg-minutes.html#action03]
<trackbot> Created ACTION-3154 - Add a section to the Requirements
document about general approaches [on Cameron McCormack - due
2011-11-03].
ED: this is a big proposal, RDML from Dr O
... I haven't read all of this, but I feel it's a bit too big to
include in SVG at least
... it feels like something that could at most be a module, or even
apply to other things than SVG
CM: I think it's quite a big feature, and out of scope for SVG2
... 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
ED: there are ways you can generate shapes from raw data right now,
using XSLT for example
CC: to me it seems linked to sXBL
CM: the Web Components work is looking at script based solutions to
begin with
... and looking at declarative solutions later
... if anything, it should be looked at as part of that effort
RESOLUTION: We will not include RDML in SVG2.
ED: next, templating for controls and widgets
<ed>
[18]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#T
emplating_for_controls.2Fwidgets
[18] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets
ED: again I think that's something on top of, or outside of SVG
CM: again I think we should look to Web Components here
... the work is gaining traction
... we should ensure though that it solves our previous use cases
for sXBL etc.
RESOLUTION: We will not include a templating mechanism in SVG2.
CM: Let's talk with Dmitri next week at TPAC about Web Components.
ED: That was all from the general section
... we don't have everything categorised yet
... next area is Rendering Model
... and next topic is z-index
<ed>
[19]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z
-index
[19] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index
ED: I believe we already resolved to include
... so we don't need to discuss that
... next, translucency
<ed>
[20]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#T
ranslucency
[20] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Translucency
ED: I didn't know exactly what was meant here
CM: I think opacity + blur filters is enough
CC: we don't have a lighting model
VH: from the description, I think we can do it with opacity and
filters
RESOLUTION: We will not include translucency support, existing
functionality is sufficient.
ED: next, flatten to image
<ed>
[21]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#F
latten_to_image
[21] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Flatten_to_image
ED: from the description I wasn't sure how this differed from the
buffered-rendering property
... seemed like the same thing to me
... it's possible he meant to throw away the DOM tree as well
... you can kind of lose scalability if you do that
CM: presumably you'd only use the feature where that is acceptable
ED: buffered-rendering does the same thing without throwing away the
DOM
CM: if you are able to paint SVG to a canvas, then you could do that
manually
ED: I think it's not a bad requirement
... flattening to a raster is useful and necessary sometimes
... I don't think we need to be very specific on how to solve it,
but we should have it as a requirement
CM: buffered-rendering is a hint, so a bit different
ED: say you had a huge canvas you couldn't allocate
... that can happen with buffered-rendering too
... it doesn't mean anything changes in the rendering
CC: I don't hink it's related to buffered-rendering
... if you put a group with 3 objects, one in the background, two
next to each other
... and put bufered-rendering on the group, you'll still see the
object from the background
ED: not sure I follow
[Cyril writes on the board]
seems we skipped one, Cyril was talking about pixel rounding
VH: I agree that we he describes is similar
... the thing he wants can be supported with libraries like canvg
... you can render it into an offscreen canvas, then insert that
canvas
... there is work going on to fix the security issue with painting
SVG content to canvas
DH: yes
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
ED: that's what he's suggesting, not sure that's what you want
always
DH: but this proposal is for a bitmap
ED: with buffered-rendering in Opera, updates will update the
rendering, but not immediately
CC: I think it's a good requirement
ED: but we can discuss the solution later
RESOLUTION: We will add flatten to image as a requirement.
<ed>
[22]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#P
ixel_rounding_methods
[22] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Pixel_rounding_methods
ED: next, pixel rounding methods
VH: this is the same issue that Michael Bostock brought up at SVG
Open
CC: well known problem
ED: I think we might have several issues/requests for this
... don't think it's a new thing
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?
... let's say a dummy implementation makes 2 passes
... 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
... from bg to fg
DH: what if you had opacity on the rectangles, maybe 99%
ED: Michael Bostock was mentioning FSAA
VH: the way people do that is supersampling on the pixels
... in the case of the line, you realise you keep hitting the same
subpixels and not creating the artifact
CC: but no implementations do that
VH: what you are suggesting is also quite complex
... even if you have full covereage for the pixel, you have to
figure out all the objects contributing to the opacity
... it's not trivial
CC: I'm just wondering whether it's incompatible with the model
... why don't we have a single browser doing it at the moment
ED: the shape-rendering hint solves some of the simple cases
VH: I think it's not there for historical cases
... it's true that it's ugly in cases, but few people care about it
CC: I think it has been raised from the beginning
VH: but if you do a powerpoint presentation, or a flow diagram, most
of those cases you'll never hit this
CC: I found this problem in flash to svg conversion
... in Flash you can have many shapes that share a border
ED: I think what people want is sharp edges
VH: maybe a new rendering hint
DH: it seems like it would be hard in general
... to do automatic pixel snapping and for that to do what you want
RESOLUTION: We will ensure there is a way to avoid getting seams on
adjacent edges of rendered elements in SVG2.
ed, [23]http://www.w3.org/TR/SVG2Reqs/
[23] http://www.w3.org/TR/SVG2Reqs/
ED: next section is Document Structure
<tbah> Phone number?
ED: namespace requirements cleanup
<ed>
[24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#N
amespace_requirements_cleanup
[24] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Namespace_requirements_cleanup
<tbah> Thanks
<tbah> ok
ED: we do have a resolution for xlink:href
... we still have xml:id and other xlink-related things
... not sure we have a resolution for that
RESOLUTION: We will reconsider use of namespaced things in SVG
(xlink, xml:id, etc.).
<ed>
[25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#.
3Cuse.3E_cleanup
[25] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#.3Cuse.3E_cleanup
VH: browsers have started to do something re href="" too
... so we should look at that
ED: next, use cleanup
CM: a bit vague
... the one issue I can think of is the property inheritance into
the shadow tree
CC: when you have a use element that includes a reference to a
gradient, you need to duplicate the whole shadow tree each instance
ED: one part might be differences between implementations
... ensuring things work the same
... that could require having a second look at the current spec,
seeing what's broken and what's differing
VH: I would suggest taking this as a need for a better
referencing/cloning mechanism
... I would accept this as a requirement, since it's a pain point
for many people
RESOLUTION: We will require a feature that allows symbol reuse
without requiring duplication of shadow trees in SVG2.
<ed>
[26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#M
arker_cleanup
[26] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Marker_cleanup
ED: next, marker cleanup
... we have one resolution already, to add currentStrokePaint etc.
... for inheriting colours into the marker
... which seemed to be the thing most people were asking for
... I think as a requirement, we should probably look a bit wider
... on how to improve markers
RESOLUTION: We will improve markers for SVG2.
<ed>
[27]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
hadow_tree_cleanup
[27] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shadow_tree_cleanup
ED: next, shadow tree cleanup
... not sure if that's different from use cleanup
... I think that could be the same thing
... next one is "improve the DOM"
<ed>
[28]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
mprove_the_DOM
[28] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM
ED: we have a bunch of different proposals
... I've collected some of them as subpoints of this item
... so we could resolve on those
... it's more contained, simplified
... first of those is "improve the DOM for SVG Animation"
<ed>
[29]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
mprove_the_DOM_for_SVG_Animation
[29] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM_for_SVG_Animation
VH: yes
ED: I proposed a simple API to grab the current motion animation
... that's been asked for a number of times
DH: supposing the element itself is transformed, does this take into
account all of the element's transforms?
ED: just the transform for the motion animation
CC: we don't have a microdom equivalent for that?
ED: don't think so
<ed>
[30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AnimateMotion_D
OM_API
[30] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AnimateMotion_DOM_API
RESOLUTION: We will expose animateMotion values in the SVG DOM in
SVG2.
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"
... two implementations already do this
... I think I have the action to add that
<ed>
[31]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#M
ake_it_easier_to_read_and_write_to_attributes_in_the_DOM
[31] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM
ED: next is "make it easier to read/write attributes in the DOM"
[discussion about issues with SVGAnimatedLength]
RESOLUTION: We will make it easier to read and write to attributes
in the SVG DOM in SVG2.
<ed>
[32]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
mprove_the_SVG_path_DOM
[32] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_SVG_path_DOM
ED: next is improve the SVG path DOM
VH: agree
ED: not entirely clear what to do, but the SVGPathSegList interface
is horrible
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
<shepazu> +1 to shared graphics API
VH: do desktop browser implement any 1.2T dom?
ED: just Opera I think
... for path api, I like the one in Tiny more
... it's not perfect, but better
RESOLUTION: We will improve the SVG path DOM APIs in SVG2.
<ed>
[33]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
_way_to_access_.28presentational.29_property_values_easily
[33] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A_way_to_access_.28presentational.29_property_values_easily
ED: next, way to access presentational property values easily
CC: getPresentationTrait?
ED: similar, Jeff was saying that it's hard to get the colour value
of some fill or stroke
... if you have to use the CSSOM, it's pretty bad
... maybe even more dots than the SVG DOM
... and it's not usually very well implemented
CM: is this just an issue for the CSSOM spec?
ED: that, or we could address it with a trait access interface
... I'm not 100% sure that CSSOM will allow accessing base and
animated values
RESOLUTION: We will coordinate with other WGs to ensure improved
property value access to SVG properties in SVG2.
<ed>
[34]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#M
ake_it_possible_to_get_the_bounding_box_of_an_element_in_a_particula
r_coordinate_system
[34] 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
ED: next, make it possible to get a bbox of an element in a
particular coordinate system
... this is a pretty detailed requirement
... I think we should probably look at a few different things
related to this
... I know we had in 1.2F reqs, the requirement to get bounding
boxes with strokes, markers, etc.
... I think that's we something we definitely should have in SVG2
... getting hte bounding box in different coordinate systems
... what coordinate systems?
... we have getScreenBBox
VH: is there a proposal for how this would be done?
... if you could have a target element parameter to getBBox, that
would be handy
CM: getBoundingClientRect was suggested as a way to include stroke
JY: that doesn't work if the element is out of the viewport, though,
I found
RESOLUTION: We will improve bounding box method APIs in SVG2.
ED: a couple more big things about improving the DOM, haven't been
split into subcategories
<ed>
[35]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
mprove_the_DOM
[35] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_the_DOM
RESOLUTION: We will generally improve the SVG DOM for SVG2 (specific
proposals to be resolved on later).
<scribe> ACTION: Cameron to add Improving the SVG DOM as a design
approach/direction to the Reqs document [recorded in
[36]http://www.w3.org/2011/10/27-svg-minutes.html#action04]
<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].
<ed>
[37]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
utomatic_fetch.2Fdiscard_of_subtrees
[37] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Automatic_fetch.2Fdiscard_of_subtrees
ED: next is "automatic fetch/discard of subtrees"
CC: Is that discard element from 1.2T?
CM: sounds more like tiling, or automatic resource fetching from the
server according to zooming/panning
ED: let's wait until Chris is here for that one
<ed>
[38]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
dditional_generic_element
[38] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Additional_generic_element
ED: next is "additional generic element"
... in 1.2T we have role/rel/rev/etc.
<cyril>
[39]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#r
ole.2C_rel.2C_rev.2C_about.2C_content.2C_datatype.2C_property.2C_res
ource.2C_typeof
[39] 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
CC: not sure what he means with "structure" content
ED: you could use html content as structured elements in there
RESOLUTION: We will not add a new semanticless SVG element to hold
role/rev/etc. attributes to SVG2.
<ed>
[40]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
llow_viewBox_on_image
[40] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_viewBox_on_image
ED: next, "allow viewBox on image"
<shepazu> why not?
CC: they can use rdf elements for that
<shepazu> might be useful to add RDFa and microdata attributes
shepazu, that's a different issue which we haven't got to yet though
<shepazu> oh, sorry, no new element… that's fine
ED: for viewBox on image, don't we already allow that?
DH: we allow preserveAspectRatio, but not viewBox
... for SVG images, it takes the viewBox from the image itself
... preserveAspectRatio="defer" exists to mean take the pAR value
from the referenced image
ED: I think it would be useful to be able to select a part of any
image
DH: there's functionality for this in CSS3 Images
... I guess this would be in xlink:href="" on <image> though
... the CSS way is to include it in the url fragment
... I worry about having different ways to do this depending on the
context
... we do already support viewBox for a number of other things,
though
... so this would just override the viewBox from the SVG image if it
has its own?
... or does it refer to a subregion of what's displayed
ED: I think in some cases you want percentages, lengths... viewBox
doesn't give that functionality
CC: the viewBox uses the coordinate system of the parent document,
which might not be consistent with the child document
DH: I don't think it would in this case
RESOLUTION: We will have a method for <image> to select a part of an
image to display, maybe by allowing viewBox on it.
<ed>
[41]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
uto-sized_image
[41] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Auto-sized_image
ED: next, "auto sized image"
... I think being able to leave off width/height and taking it from
the image you're loading
DH: would that just resolve to 0 for SVG images with %age size?
ED: undecided
... Chris says maybe, because you don't always want to scale the
image
CM: is there a way to get natural width/height of an image in SVG?
ED: no, not like in HTML
RESOLUTION: We will allow auto-sized images in SVG2.
ED: next, accessibility
<ed>
[42]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
ccessibility
[42] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Accessibility
ED: more of a general thing
CM: not sure what accepting "accessibility" as a requirement exactly
entails
... we do want to improve on the title/desc element only situation
ED: we have aria we will include, too
RESOLUTION: We will keep accessibility in mind when designing new
features, and improve existing features where we can, in SVG2.
ED: next, level of detail control
<ed>
[43]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#L
evel_of_detail_control
[43] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control
<stakagi>
[44]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#Visibilit
yControllingAccordingToZooming
[44] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming
CC: is that proposal targetting 1.2T?
ST: it isn't designed to be limited to just 1.2T
ED: I think level of detail is something I would like
<stakagi> definition of view scale is a bit unsteadily
ED: if I was doing something like this, I would want to try to keep
it as a CSS property
... or presentation attribute
CM: to say valid at certain zoom level?
ED: yes
... would be nice to write style sheets where certain things get
hidden depending on the zoom level
<tbah> Conference call timed out... but I think I'll call it a night
so don't bother restarting.
tbah, ok, thanks for calling in!
CM: Let's talk with Chris about that one when he is in
<ed>
[45]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
isplay_of_InkML_trace_groups
[45] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups
ED: next, display of InkML trace groups
... he saying that if you draw it with SVG, you have to add lots of
DOM nodes
... and it gets heavy
CC: he says it would be fantastic to be able to draw inkml trace
groups
... but he is first looking for solving the earlier issues that
prevent him using svg
ED: it's hard to say without having some example
CC: there are two points here
... one is "bitmap accumulation"
... "the two reason i continue to use canvas svg ... is bitmap
accumulation and n-dimensional trace groups"
<scribe> ACTION: Cameron to contact Charles about
[46]http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to
clarify with examples the "two areas most-lacking in SVG" [recorded
in [47]http://www.w3.org/2011/10/27-svg-minutes.html#action05]
[46] http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html
<trackbot> Created ACTION-3156 - Contact Charles about
[48]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].
[48] http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html
<ed>
[49]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#P
laceholder_graphics_for_unresolved_images
[49] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Placeholder_graphics_for_unresolved_images
ED: next, placeholder graphics for unresolved images
CC: if the link is broken you want to display something, I think
that is a reasonable requirement
CM: does switch and eRR work?
CC: no
VH: I would do the same thing that HTML does
JY: I think customising is a bit much
DH: in standards mode in Gecko, HTML images do not render
placeholder images any more
... but anyway you can't customise them
... I think unless there's a huge desire from authors, it might be
less useful
ED: I think it makes sense to be the same as HTML
CL: people testing their content might want different behaviour to
the end user
<ed> DH: webkit and opera both render placeholder images in html,
even in non-quirks mode
[50]http://www.w3.org/2009/05/20-svg-minutes.html#item05
[50] http://www.w3.org/2009/05/20-svg-minutes.html#item05
JY: I'd only support it if it applied HTML content as well
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
RESOLUTION: We will not have a feature to provide broken image
fallback content, unless specific proposals are worked on further.
The ISSUE-2040 and the two actions ACTION-2567 and ACTION-2568 on
jwatt and chrisl
<ed> -- break for lunch --
<cyril> Scribe: Cyril Concolato
<cyril> ScribeNick: Cyril
<ChrisL> Topic; SVG Glyphs in OpenType fonts
Hinting or multi-resolution switching, and other issues with SVG glyphs
in OpenType fonts
CM: Sairus is here and wants to contribute in this area
SP: various use cases: tablet PC magazines, emoji ...
... we would like to have color and animations
... SVG Fonts seem on a deprecated path
... bringing open type would be an advantage
... there is a couple of issues
CL: I've seen several proposals
<ChrisL> adam twardoch
SP: Adam Twardoch brought up on the opnetype list a proposal where
an SVG font would be in an Open Type font
[SP explaining OpenType / OFF on the board]
scribe: cmap provides unicode - glyph id association
<ChrisL>
[51]http://lists.w3.org/Archives/Public/www-style/2011Jun/0636.html
[51] http://lists.w3.org/Archives/Public/www-style/2011Jun/0636.html
scribe: TrueType had various glyf tables
<ChrisL> Si Daniels (Microsoft)
[52]http://www.typecon.com/archives/646 OpenType, in Living Color?
[52] http://www.typecon.com/archives/646
scribe: Some said we like some tables in OpenType, but we don't like
OpenType outlines
... that's why there is CFF (Compact Font Format) outlines
... you have truetype or CFF rasterizer
... we would like to have a 3rd type of outlines: SVG, but
everything else would be the same
'SVG '
scribe: the content of the outline could be an SVG <font> element
... another proposal would be to have a full <svg> document per
glyph
... another proposal, is having a single <svg> document for all
glyphs but a glyph referenced inside
<shepazu> (how about <glyph id="a"> </glyph> ?)
scribe: we would have to make clear the correspondence between glyph
id and SVG id
... that 3rd option has several advantages: single timeline if there
is an animation for hte glyphs
... the first option (SVG <font>) has some redundancy (encoding ...)
... like CFF has problems
... I want to discuss a model where a single SVG document is needed
... I want to discuss security
... secure animation mode (no arbitrary download, scripting ...)
CL: you don't need to get rid of scripting to insure security
<shepazu> (no external reerences, etc.)
<shepazu> (I'm happy to add this use case to SVG Integration spec)
CL: you can say scripting has no access to the DOM, but is
constrained to access to the font it's embedded in
SP: allowing scripting, how could someone argue that it would be a
bad thing
CL: you could always have DoS attack, ... but if the script is able
to access the document there is a proble;
<shepazu> (in short, we can add whatever "mode" or feature
restriction we need, and which is technically possible, to SVG
Integration)
CL: if you sandbox the script, if its self contained, there would be
less problem
SP: one item would be defining the restriction mode we want
CL: I prefer that to restricting to no use of script because it
might be useful
ROC: each instance of the font will have its own script context
<shepazu> (we could simply add security errors to dangerous methods
in this context)
ROC: the other issue, SVG as images has some issue with regards to
loading of resources
... we would want to impose the same restrictions on font as on
images for simplicity
CL: I understand that point but disagree
... font designers want to use that feature (script)
<shepazu> (adaptive connections and such?)
CL: it cuts off too many uses cases
SP: so far fonts have been predictible
<shepazu> (I'd love to see the scripted font use cases)
SP: today you can construct malicious fonts
... our current font formats are not beyond security problems
ROC: what are the real use cases ?
<shepazu> (I expect that randomness in glyph distortion would be
nice)
CL: font designers talked about randomization
... I' m happy to go back to them and ask specific use cases
ROC: we could have a version 1 without scripting
... and then a v2 with scripting
... if you rely on script first and realize it's a bad idea, you
cannot go back
PS: we could see how fast such fonts are used in workflows
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
... scripting is a way to do animation cross-browser
ED: if you don't have scripting, you cannot do feature detection for
certain browsers
ROC; it's given that the script in the font should not access the
DOM that's using the font
scribe: we would have also to decide about each API to see if it's
wanted or not, that's a huge work
CL: the answer to most question is no, we would only make a positive
(short) list of allowed API
... I'm not saying it's free or easy, I'm saying it's valuable
... there are font technology allowing arbitrary to run python, but
not in browsers
ROC: we can get things out quickly if we don't put script in in the
first place
SP: number 3 option (one single SVG document)
... Apple has invented the 'sbix' table (not yet published) contains
images for color but non-animated emoji
... this is a very big table
... it's not scalable
... Apple thinks colored emoji is fine, but they don't see the need
for animations
... Adobe definitely wants scalability and animations
... we'd like not to invent an additional table for hand tuned
animated/colored bitmaps
... making SVG look good at small font size would be a better
solution
... like hinting
... it should look good in text messages (circles, smiley faces with
eyes)
DH: non scaling strokes could help font that
CL: it's in SVG Tiny 1.2 and will be in SVG 2
PS: the stroke won't necessarily snap
CL: at one point, we looked at Type 1 for hinting of SVG fonts
... we did not feel that TrueType hinting applied well to SVG
... because of slanting, orientation and fixed font size, not at
arbitrary rotation, scale ...
PS: a Type 1 type model of hinting could be invented for SVG, but
the animation part would have to be dealt with
SP: smiley face should be snapped on pixels, but when it moves you
couldn't do snapping the same way
... maybe it's impossible
CL: we could have two modes: disable pixel snapping when it's moving
CM: we have the rendering properties
... for that
... that's what you want to use for the animation
... geometricPrecision
CL: hinting is turned off on some platforms (MacOS)
... on windows vertical or horizontal is off too
... the emphasis on hinting seems to be shifting
... the range of device resolutions is diverging
... so the 'sbix' solution cannot be future-proof
CM: we also discussed something similar to CSS media queries
... in the past, but it did not go in the spec
... but you could use a raster image instead of SVG for small sizes
CL: [explaining optical scaling]
CM: if SVG did not put hinting or features for small size, how
useful would SVG be ?
PS: hard to answer
... I could see lots of use cases for SVG at large ppm
... especially with animations (magazines, ePub)
... I wanted to check about option #3: a single SVG document
CM: the svg document can be quite big
... but the font engine would not be required to load all of it
CL: unless glyphs share resources
CM: I was wondering if we could combine option 1 & 2, have 1
document per glyph but
s/1 & 2/2 & 3/
scribe: being able to have a shared document
CL: we could construct an on-the-fly SVG document based on OpenType
tables
PS: the <glyph> element has problems
CC: this would require a pre-process to construct the document
PS: the OpenType engine would do that, yes
CM: that's an issue between the OpenType engine and the SVG engine
PS: in Flash, we try to memory map the whole file if the device has
enough memory
... and the CFF engine does not need a lot of memory
... for ex a full Japanese font on an Android device
... I don't know if SVG renderer need a copy of the SVG
CM: most of the time, the SVG engine gets SVG from the network by
chunks
PS: we don't want to create documents for each key stroke
CM: you know the initial set of glyphs required (possibly an empty
SVG document running in the background)
... as more glyphs are required, you parse the glyph outlines and
you insert them in the document
CC: you would need to delete some of them
CM: it could be an implementation issue
PS: is such interface possible between an SVG engine and an OT
engine
CM: you probably want to use an off-the-shelf engine
ROC: if the child can be inserted in any order, you can use CSS
style selectors
<heycam> ROC: with CSS selectors, the exact order that the runtime
insertions of the <glyph> elements can have an effect
<heycam> ROC: even without script
ROC: I think an SVG engine could be used
CM: when you have a large font, you need to have all glyphs in the
document, that would consume a lot of memory
... one thing is the actual text and the other is the actual DOM
element in memory
ROC: we could use display:none
CM: is it necessary for these glyph elements to be in the DOM ?
<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
<heycam> ROC: but would screw up animation timelines
CL: what about the range of characters that the SVG outlines
PS: you could indicate to which characters the SVG glyphs correspond
... today there's is nothing preventing from mixing CFF and TT
outlines in one font
... we could have a new signature for OT fonts with SVG outlines
... or define a fallback when SVG fonts cannot be used
CM: coming back to the issue of the big table
... how big a problem would be the memory problem
PS: hard to say
<heycam> ED: what if you reference the same font with text inside
the font?
<heycam> CL: we should disable that and other things, such as
foreignObject HTML
PS: what would be the big picture of someone wanting to implement
that ?
... in ebook reader and so on
... out of the context of browsers
CC: at SVG Open, we learned that ebook readers actually use browsers
... at least 4 of them
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
CL: there is a need for font expertise and SVG expertise, why not
use a Community ?
<ChrisL> s/Community/Community Group/
<ChrisL> [53]http://www.w3.org/community/
[53] http://www.w3.org/community/
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
... the state of the document in memory is not exactly what you want
to render
... you could do: grab that element in that document and draw it
somewhere else
CC: you could use the import node API
ED: you could also switch on the glyph id
<ChrisL>
[54]http://www.w3.org/community/groups/proposed/#svgopentype
[54] http://www.w3.org/community/groups/proposed/#svgopentype
ED: another option could be to use nested SVG documents: one svg
document per glyph in a bigger SVG document
<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/
PS: what about when animated fonts need to be printed ?
ED: you can use the snapshotTime attribute to indicate what is the
preferable printed version of the glyph
CM: but it depends on the SVG rendering engine and it's API
<ed> -- coffeebreak --
Text-to-path API
<heycam>
[55]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_to_path_AP
I
[55] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_to_path_API
<jen> CL: what's it's for? do you want it to be hinted?
<jen> CM: having unhinted text would be okay. using text-rendering
would ensure normal text is fine
<ChrisL> (group is created,join here
[56]http://www.w3.org/community/groups/#svgopentype )
[56] http://www.w3.org/community/groups/#svgopentype
<ed>
[57]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Add_a_DO
M_method_for_getting_glyph_path_data
[57] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Add_a_DOM_method_for_getting_glyph_path_data
Requirements input for SVG2 (continued)
UNKNOWN_SPEAKER: there was a level of zoom requirement item too
... just put an attribute for minimum/maximum zoom level on any
element
CM: the Tiling/Layering will be a separate document, right?
CL: that won't allow you to do the complex/simpler path kind of
level of detail though
[discussion of differences between tiling, LoD, auto fetch/discard]
RESOLUTION: We won't include automatic fetch/discard in SVG2.
<ed>
[58]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#L
evel_of_detail_control
[58] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control
CM: this one sounds more interesting to me
<ChrisL>
[59]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#Visibilit
yControllingAccordingToZooming
[59] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming
RESOLUTION: We will support Level of Detail control in SVG2.
<ed>
[60]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#T
emplating_for_controls.2Fwidgets
[60] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets
CC: now the one we should go back to is templating for controls and
widgets
<ed> ED: already resolved earlier this morning
<ed>
[61]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_transform.3D.22.22_to_.3Csvg.3E
[61] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_transform.3D.22.22_to_.3Csvg.3E
ED: next, transform on svg elements
CL: what does that help with?
ED: nested svg elements
CM: seemed odd to me not to allow transform on svg
... but it might be confusing for authors wrt order of application
of transform and viewBox
RESOLUTION: We will allow transform on <svg> in SVG2.
ED: next, allowReorder on switch
<ed>
[62]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
dd_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switc
hing
[62] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switching
CL: this came out of a request from mozilla that switch with
requireLanguage is less useful when you have a list of ordered
preferred user languages
... it got added in SMIL3
CM: it has a bad name
RESOLUTION: We will support a mechanism like or the same as
allowReorder from SMIL3 in SVG2.
<ed>
[63]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
llow_referencing_root_external_files_with_.3Cuse.3E
[63] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_referencing_root_external_files_with_.3Cuse.3E
ED: next, allow referencing root external files with use
<ChrisL> ISSUE-2238:
DH: with <use>, you get the same animation timeline, vs if you use
image
CM: also with events you can distinguish which shadow tree elements
was clicked, for example
DH: would this apply to other things that reference external
elements, like mask?
ED: maybe wouldn't make sense there
CC: there is the animation element in 1.2T, is that relevant here?
ED: but that only references a whole document anyway
CL: in 1.2T we split it up into <image> for more static images, and
<animation> for animated ones
... with <animation> you can use the SMIL timing attribtues on it,
so you can control its timeline separately
... but you can't do that with animated SVG referenced from <image>
... the name animation is confusing though, compared to animate
... in the end though image was able to point to svg content
... so we may or may not want to keep <animation>, possibly renamed
RESOLUTION: We will relax referencing requirements to particular
elements to allow dropping fragments to mean referencing root
element, where it makes sense, such as with use, in SVG2.
<scribe> ACTION: Cyril to investigate whether more than use would
benefit from relaxing reference requirements so that "blah.svg"
refers to the root element [recorded in
[64]http://www.w3.org/2011/10/28-svg-minutes.html#action01]
[64] http://www.w3.org/2011/10/28-svg-minutes.html#action01
<trackbot> Created ACTION-3157 - Investigate whether more than use
would benefit from relaxing reference requirements so that
"blah.svg" refers to the root element [on Cyril Concolato - due
2011-11-04].
<ed>
[65]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#P
arameters
[65] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Parameters
ED: next, in the Attributes section, is Parameters
CC: we need this
DS: we decided last time that we would not make this general
CC: in what sense?
DS: in the sense that this would not be a CSS thing, it's an SVG
thing
... although people are going to want to pass things in to CSS
... in CSS embedded in SVG, you would want a legal value to be a
param
... I think we thought it would take too long to get into CSS as
well
... but having it attribute only would have this downside
... especially if people are using SVG and CSS together more
CM: I would really like to see if we can use CSS Variable as the
in-CSS way to reference parameters
DS: maybe we should move ahead with it as a separate spec
CL: Tab is in general happy to add new values to CSS Values
DS: it's effectively like calc, in terms of scope
... I see param working with calc really well
CC: do we want to allow params to work with presentation attributes,
style properties, geometry attributes, SMIL attributes...?
DS: I want it to apply to every SVG attribtue, and maybe property
values as well
CC: how about using them in script?
DS: there's the DOM interface that exposes params and their values
... anything I do with params I would like to decompose a shorthand
for Component Model
[discuss some details of Params]
DH: I would be a bit concerned about being gated on CSS work
DS: we could say that for now, it works only in attributes, but that
we're open to the CSS WG allowing this in property values
... and I'd expect there'd be experimental implementations to see if
there are any issues with allowing that
CL: we did already talk about this within FX
RESOLUTION: We will have Parameters in SVG2, worked on in a
normatively referenced separate spec.
Summary of Action Items
[NEW] ACTION: Cameron to add a section to the Requirements document
about general approaches [recorded in
[66]http://www.w3.org/2011/10/27-svg-minutes.html#action03]
[NEW] ACTION: Cameron to add Improving the SVG DOM as a design
approach/direction to the Reqs document [recorded in
[67]http://www.w3.org/2011/10/27-svg-minutes.html#action04]
[NEW] ACTION: Cameron to contact Charles about
[68]http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to
clarify with examples the "two areas most-lacking in SVG" [recorded
in [69]http://www.w3.org/2011/10/27-svg-minutes.html#action05]
[NEW] ACTION: Cyril to start a wiki page on SVG2 spec structure,
showing which are split out into modules [recorded in
[70]http://www.w3.org/2011/10/27-svg-minutes.html#action02]
[NEW] ACTION: Erik to write up a wiki page on SVG2 editing and
procedure [recorded in
[71]http://www.w3.org/2011/10/27-svg-minutes.html#action01]
[NEW] ACTION: Cyril to investigate whether more than use would
benefit from relaxing reference requirements so that "blah.svg"
refers to the root element [recorded in
[72]http://www.w3.org/2011/10/28-svg-minutes.html#action01]
[68] http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html
[72] http://www.w3.org/2011/10/28-svg-minutes.html#action01
[End of minutes]
--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups
Received on Friday, 28 October 2011 04:23:27 UTC