See also: IRC log
<trackbot> Date: 27 October 2011
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
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: 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
... 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].
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
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
... 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
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: 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
... we don't have everything categorised yet
... next area is Rendering Model
... and next topic is z-index
ED: I believe we already resolved
... 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 filters
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
... 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
... 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
... 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
... 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
... 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
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: 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
... 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: next section is Document Structure
<tbah> Phone number?
ED: namespace requirements cleanup
ED: we do have a resolution for
... 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
... 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
... 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
... 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: 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 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: 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
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: next, way to access presentational property values easily
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 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: 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
... 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 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: next, "auto sized
... 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?
... 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: 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
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?
... 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
... 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
... 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: 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?
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
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
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
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
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
... we would want to impose the same restrictions on font as on images for simplicity
CL: I understand that point but
... 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
... 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
... I' m happy to go back to them and ask specific use cases
ROC: we could have a version 1
... 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
... 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
... 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
... maybe it's impossible
CL: we could have two modes: disable pixel snapping when it's moving
CM: we have the rendering
... for that
... that's what you want to use for the animation
CL: hinting is turned off on some
... 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
... 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
... 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/
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
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 --
<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 )
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.
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 widgets
<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
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
... 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: 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.