- From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- Date: Fri, 18 Oct 2013 08:34:39 +1100
- To: <www-svg@w3.org>
Minutes from this week's SVG WG telcon are below.
html version:
http://www.w3.org/2013/10/17-svg-minutes.html
text version:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
17 Oct 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0016.html
See also: [3]IRC log
[3] http://www.w3.org/2013/10/17-svg-irc
Attendees
Present
Regrets
Erik, Luc, Tav, Rich
Chair
Cameron
Scribe
nikos
Contents
* [4]Topics
1. [5]Publish CSS Masking as LCWD
2. [6]Should perspective affect object bounding box of
SVG elements?
3. [7]Confirm location and dates for 1st F2F of 2014
4. [8]SVG Glyphs in OpenType specification
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 17 October 2013
<stakagi> zakim ??P6 is me
<scribe> scribenick: nikos
Publish CSS Masking as LCWD
krit1: Can we publish?
<krit1>
[10]https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
[10] https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
krit1: short summary about changes
... syntax hasn't changed except one exception
... initial draft supported multiple layers of mask
... question was if it's possible to combine different masks or
if it would be mask on mask
... so we delayed layers to next level until this is workedo ut
heycam: so you can only specify one layer
krit1: yes
... having multiple mask layers can be useful but how do you
combine the mask?
... in webkit, you mask with each in turn
... but you might want to combine masks and then apply
... needs to be discussed more
... not worth waiting
heycam: should be possible to define the first process you
said? applying masks in turn
... should be possible to compute a single mask that does that?
krit1: the problem is you always lose something
... imagine having a composite operator between the masks and
then apply the result
heycam: I think it's fine to leave that to later
cyril: what is the difference compared to what svg had in the
past?
... are features different or just css integration?
krit1: the idea was to have a spec for html and svg world
... yes when combined with mask-box
... no because you could do a lot of things with svg mask
element that you can now do with masking using an image
... it gets easier, but not necessarily more powerful
birtles: we do have alpha and luminance masking
krit1: both are implemented in webkit as of a couple of weeks
ago
<birtles>
[11]http://lists.w3.org/Archives/Public/public-fx/2013OctDec/00
56.html
[11] http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0056.html
birtles: did you see the discussion on public-fx on how how the
properties are animated?
krit1: all properties define if animatable or not
... what will work on mask properties will also apply to
background properties
... mask-box-image-slice is not animatable at the moment
heycam: is the background version of image-slice property
animatable?
krit1: yes it's called border-image-slice
heycam: why is the mask one not animatable?
krit1: I think it's the auto value cannot be animated
... but I think maybe it could be
RESOLUTION: publish LCWD of CSS Masking.
heycam: which group will handle publication?
krit1: I asked ChrisL to handle it
Should perspective affect object bounding box of SVG elements?
krit1: object bounding box is a construct we have in svg for a
long time
... it's the union of all bounding boxes of it's children
including transforms
... as an example. You have group element with child rect.
Child rect has scale of 2 then bounding box of the rect will be
twice as big for the group element
... CSS transforms we have a lot more properties
... importantly, persepective and perspective-origin
... the persepective has percentage values
... the spec currently says for all properties, percentage
values are resolved against object bounding box
... if the object bounding box includes perspective there is a
circular dependency
... one option is to stick to definition of svg 1.1
heycam: that means ignoring the transform property and all of
the other perspective
... can you remind me what is the plan for transform
presentation attribute and property?
... are they meant to be the same thing?
krit1: transform attribute will be presentation attribute
... that means for transform property we have cascade
... so you could just look at the presentation attribute not
the whole cascade
... I don't think we should go that way though
heycam: I agree
krit1: other solution is object bounding box does not included
perspective
... so that we do not have the problem resolving
... third solution - all percentage values are resolved against
the viewport
heycam: do we have to consider the transform properties because
we might have the individual perspective properties in that
list?
krit1: I don't think that's a problem. They apply as a
transform function
... no dependency on parent or child
heycam: if you have transform-origin with percentage values and
transform property with list and one is a perspective
... would there be a cyclic dependency?
... what's different?
krit1: transform just takes transform functions that are
multiplied together
... persepective is not an exception
... it's just another function
... I would suggest we look at the 3d part
... for getting the bounding box
... perspective property on other hand is devised from the
parent
... parent perspective multiplied by transform of current
element
... that's the difference
... between perspective function and property
... I don't think it's actually that useful
heycam: option 2 was to ignore perspective property when
calculating the bounding box
... is that all situations (getBBox as well as bounding box for
gradients for example)
krit1: it should be all situations
... the problem with option 3 is it's not intuitive
... and doesn't fit well with html world
... would also be different to transform and transform-origin
heycam: if you add a small amount of perspective and
transform-origin is in a different position, that would be bad
krit1: in general perspective and 3d transforms are complex
... can wait on a resolution if people need time to digest
heycam: my feeling is that number 2 sounds like the best
krit1: I'd be in favour of 2
heycam: in html if you have perspective and call getClientRect
... how does that work with perspective, etc
krit1: main difference is that getClientRect does not included
transforms
heycam: is there no function for getting actual bounding box
with transforms in html?
krit1: transform doesn't modify the layout
<krit1> shepazu: speak!
shepazu: you're talking about whether perspective should change
getBBox()?
... Dirk you were saying no?
krit1: correct
... perspective on child element comes from the parent. Problem
is that perspective can have percentage values that need to be
resolved against object bounding box. But object bounding box
needs the percentage values to be calculated
... bounding box inclueds the size of transformed children, but
not the transform on the actual element
s/is modified by/inclueds/
shepazu: I'd like to see it written up
krit1: we need a solution for resolving the dependencies
heycam: the issue is when you use percentage values in
transform-origin and the percentages are relative to the shape
you are transforming. But the perspective can change the
bounding box of the shape being transformed
... so there's a cyclic dependency
shepazu: there's an internal way of getting the bounding box
right?
... but that's not what we're exposing to the user
... we are exposing a convenience function
heycam: the issue isn't calculating the bounding box. The issue
is having the percentage values influence the bounding box
... this isn't the case for regular transforms or html content
shepazu: I'd like to see a diagram of this to clarify
krit1: the browser has this problem internally
... we could move discussion to the mailing list? I tried to
explain on public-fx
shepazu: there's the bounding box - the internal calcualtion of
this
... and the return value of the get bounding box function
exposed to users
... they don't have to return the same result
... we could introduce a change to affect this
... I'll try to explain
... let's say we have a new bounding box function getBBox2
... it can return whatever we want because there's no
dependency chain
krit1: it can't be calculated internally
... we expose exactly what we calculate internally
heycam: implementations at the moment. If they supported 3d
transforms on SVG. There is no way to mathematically resolve
the percentage values
shepazu: I think we're talking about two different issues
[heycam summarises]
krit1: let's continue on the mailing list
Confirm location and dates for 1st F2F of 2014
heycam: Dirk you've been co-ordinating with CSS?
krit1: CSS group is happy to meet for half day as I said
previously
... fx on second half of 29th Jan
... SVG on 30-31 Jan
... in Seattle
... I've booked the rooms
RESOLUTION: SVG WG will meet in Seattle 30-31 January 2014 with
FX half day on 29th January
SVG Glyphs in OpenType specification
heycam: There was a second coloured fonts meeting which Chris
was at
... he sent a summary to the list
... that was one of the reasons Sairus wanted the spec
stabilised
... the spec will serve as introduction to the discussion for
ISO in January
... so that was the point of moving the community group draft
to spec text
cyril: Chris is saying there are 4 proposals
... Microsoft's, Apple's, etc
heycam: Google and Apple are bitmap formats
... Google is something like embedding PNGs
... Microsoft has solid coloured filled vectors
cyril: in terms of process. There's a call for proposals in ISO
... how does the community group satisfy the requirements?
heycam: someone needs to write up a document addressing how the
specification matches each requirement
... there are requirements around lower power devices
... it seems the list of requirements covers all the bases
[12]http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDe
c/0020.html
[12] http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0020.html
cyril: I think normally one is picked to continue and the
interesting parts of others are merged in
nikos: there's already been some merging - Microsoft palettes
into SVG in OT
heycam: one font could have the palette table plus Microsoft's
multi coloured glyph table and SVG and use the palette in both
krit1: benefits of the other proposals are that they are easy
to implement in the font system
... but they do not have animations or things like that
nikos: but there's no way to specify a colour that wasn't
already defined in the font?
shepazu: Does Adobe have a position?
krit1: I'm not sure. Sairus is obviously working on SVG in OT
but I don't know if it's personally motivated or on behalf of
the company
cyril: who will be representing SVG in OT at the MPEG meeting?
heycam: I'm not sure
... in San Jose so convenient for Sairus
cyril: meeting is 13th-17th
... I will be there
Summary of Action Items
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 17 October 2013 21:35:32 UTC