W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2011

Minutes, SVG f2f Mountain View, Thurs 27 Oct 2011

From: Chris Lilley <chris@w3.org>
Date: Fri, 28 Oct 2011 06:23:12 +0200
Message-ID: <346578864.20111028062312@w3.org>
To: public-svg-wg@w3.org

Minutes (morning and afternoon merged) at


and below as text for machine intelligences

                   SVG Working Group Teleconference

27 Oct 2011


      [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


          ED, CM, JF, ST, VH, CC, JY, DH, CL, DS, AD, Sairus Patel

          Erik, Cam

          Cameron, Cyril Concolato, Erik


     * [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
   ... 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
   ... 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

   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

   <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


     [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/

   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

   <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

   CM: so "avoid" is ok, but not never

   ED: probably don't need a resolution on this
   ... Next, generating shape data 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

   <trackbot> Created ACTION-3154 - Add a section to the Requirements
   document about general approaches [on Cameron McCormack - due

   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


     [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


     [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


     [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

   RESOLUTION: We will not include translucency support, existing
   functionality is sufficient.

   ED: next, flatten 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

   CM: if you are able to paint SVG to a canvas, then you could do that

   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
   ... 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

   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.


     [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

   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


     [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.).


     [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.


     [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.


     [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"


     [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"


     [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


     [30] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AnimateMotion_DOM_API

   RESOLUTION: We will expose animateMotion values in the SVG DOM in

   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


     [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.


     [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

   <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.


     [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.


     [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


     [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

   <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].


     [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


     [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.


     [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.


     [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

   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
   ... we do already support viewBox for a number of other things,
   ... 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.


     [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

   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


     [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
   ... 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


     [43] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control


     [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


     [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
   ... 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


     [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

   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


     [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
   ... 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

   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

   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
   ... like hinting
   ... it should look good in text messages (circles, smiley faces with

   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

   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

   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

   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


     [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


     [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


     [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

   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.


     [58] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control

   CM: this one sounds more interesting to me


     [59] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming

   RESOLUTION: We will support Level of Detail control in SVG2.


     [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

   <ed> ED: already resolved earlier this morning


     [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


     [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.


     [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

   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

   <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


     [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
   ... 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
   ... I think we thought it would take too long to get into CSS as
   ... 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
   [NEW] ACTION: Cameron to add Improving the SVG DOM as a design
   approach/direction to the Reqs document [recorded in
   [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
   [NEW] ACTION: Erik to write up a wiki page on SVG2 editing and
   procedure [recorded in
   [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

     [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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 October 2011 04:23:29 GMT