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

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 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> 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 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> 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> 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> 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> 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> 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, http://www.w3.org/TR/SVG2Reqs/

ED: next section is Document Structure

<tbah> Phone number?

ED: namespace requirements cleanup

<ed> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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 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> 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> 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> 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> 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> 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> 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> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control

<stakagi> 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> 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 http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to clarify with examples the "two areas most-lacking in SVG" [recorded in http://www.w3.org/2011/10/27-svg-minutes.html#action05]

<trackbot> Created ACTION-3156 - Contact Charles about http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html to clarify with examples the "two areas most-lacking in SVG" [on Cameron McCormack - due 2011-11-03].

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

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> http://lists.w3.org/Archives/Public/www-style/2011Jun/0636.html

scribe: TrueType had various glyf tables

<ChrisL> Si Daniels (Microsoft) http://www.typecon.com/archives/646 OpenType, in Living Color?

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> 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> 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> 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 http://www.w3.org/community/groups/#svgopentype )

<ed> 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> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control

CM: this one sounds more interesting to me

<ChrisL> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming

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

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