Fwd: Minutes, SVG f2f Mountain View, Thurs 27 Oct 2011

Minutes from day 1 of the F2F below.

-------- Original Message --------
Subject: Minutes, SVG f2f Mountain View, Thurs 27 Oct 2011
Resent-Date: Fri, 28 Oct 2011 04:23:29 +0000
Resent-From: public-svg-wg@w3.org
Date: Fri, 28 Oct 2011 06:23:12 +0200
From: Chris Lilley <chris@w3.org>
Reply-To: Chris Lilley <chris@w3.org>
Organization: W3C
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



    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



    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: I believe we already resolved to include
    ... so we don't need to discuss that
    ... next, 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



    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.



    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



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



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



    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



    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



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



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



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



    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: next is "additional generic element"
    ... in 1.2T we have role/rel/rev/etc.



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



    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



    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





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



    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



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.



    CM: this one sounds more interesting to me



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



    CC: now the one we should go back to is templating for controls and

    <ed> ED: already resolved earlier this morning



    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



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



    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 Saturday, 29 October 2011 01:07:20 UTC