- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 26 Jun 2014 06:49:56 -0700 (PDT)
- To: www-svg@w3.org
Minutes:
http://www.w3.org/2014/06/26-svg-minutes.html
as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
26 Jun 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0105.html
See also: [3]IRC log
[3] http://www.w3.org/2014/06/26-svg-irc
Attendees
Present
[IPcaller], ed, heycam, birtles, stakagi, krit,
Doug_Schepers, Smailus, ChrisL, Tav
Regrets
Richard
Chair
Cameron
Scribe
birtles
Contents
* [4]Topics
1. [5]Proposal: Remove altGlyph, altGlyphDef,
altGlyphItem and glyphRef from SVG2
2. [6]How should the following two SVGPathElement methods
work when there's no path data?
3. [7]Filter effects and blend modes for feBlend
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Date: 26 June 2014
<Smailus> who is on the phone
<scribe> ScribeNick: birtles
<scribe> Scribe: birtles
Proposal: Remove altGlyph, altGlyphDef, altGlyphItem and glyphRef
from SVG2
ed: I sent to the mailing list tests which I ran on all the
different browsers I could find
<ed>
[9]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0084.htm
l
[9] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0084.html
ed: this test was to verify that altGlyph doesn't work on
normal fonts that are not SVG fonts
... I couldn't find any browser that did that
... the only browsers that supported altGlyph only did so for
SVG fonts
... so since we're removing SVG fonts it makes sense to remove
these as well
heycam: makes sense to me
ed: if you look at the test itself
... I wasn't sure how to reference glyph IDs so I used various
ways
... but none of them worked
heycam: it might have interesting the spec actually said what
the syntax was for referencing glyphs from different font
formats
ChrisL: I don't think there is an approved way of pointing into
a table in a binary font format
... that syntax was only ever intended for SVG fonts
heycam: anyone against removing these from SVG2?
(silence)
RESOLUTION: We will remove altGlyph and company from SVG2
<ChrisL> +1
Smailus: I agree
<scribe> ACTION: Erik to remove altGlyph and company ffrom SVG2
[recorded in
[10]http://www.w3.org/2014/06/26-svg-minutes.html#action01]
<trackbot> Created ACTION-3632 - Remove altglyph and company
from svg2 [on Erik Dahlström - due 2014-07-03].
How should the following two SVGPathElement methods work when there's
no path data?
ed: I did what we discussed on the last call and posted to the
mailing list with various options from the browsers
<ed>
[11]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0126.ht
ml
[11] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0126.html
ed: I listed a bunch of different proposals
... the email thread also had a few more suggestions
... for the first one, getPointAtLength, that returns an
SVGPoint
... one suggestion from Dirk was to return undefined
<ed>
[12]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0132.ht
ml
[12] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0132.html
krit: or null? does nullable return undefined or null?
heycam: returning undefined is a bit difficult from IDL
... it doesn't really happen in other APIs, generally we return
null
... I would suggest that over undefined
ed: would that be stringified to 0... ?
heycam: I would suggest we change the IDL to SVGPoint? so that
null can be returned as is
<krit> null
ed: so if you're expecting to get an SVGPoint back you'd have
to check the return value point for
heycam: sorry, I was referring to the other method
... last time I think we discussed the pros and cons of objects
with NaN members vs returning a null value
... if the object has NaN values the code would probably
continue further but it might make it harder to track down
problems later
... anyone prefer NaN x/y values?
ed: Dirk suggested in the mail that that might be ok
<krit> I am fine with null or SVGPoint(NaN, NaN)
Smailus: I prefer making something clearly an error
krit: if you search GitHub for these two methods you won't find
any results except test cases
<ChrisL> agree, returning a potentially valid value is
suboptimal (even if a second call can disambiguate it)
krit: to give you an idea how important they are
birtles: I slightly lean towards SVGPoint(NaN, NaN) but null
may be ok too
<krit>
[13]https://github.com/search?q=getPointAtLength+extension%3Asv
g&type=Code&ref=searchresults
[13] https://github.com/search?q=getPointAtLength+extension%3Asvg&type=Code&ref=searchresults
heycam: Tab mentioned that there's a similarity with
getBoundingBox
... in the end we settled on making getBoundingBox on an empty
group return rect(0, 0, 0, 0)
... but if you called getBoundingBox on a parent of that, that
0 point wouldn't contribute to the parent's bbox
Smailus: so that's an argument for returning 0 to keep things
consistent
ChrisL: there's many different things we could be consistent
with
<ed>
[14]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0140.ht
ml
[14] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0140.html
ed: Tab also mentioned that it's not defined if you use an
distance larger than the lenght of the path
heycam: and for getPointAtLength you could use a length greater
than the length of the path
... Tab said in that same mail that if you defined what
happened if you passed in a length that's too large then you
probably would use the same behavior
... I'm inclined for it to be 0,0 if there's no path data
Smailus: I support that
<ChrisL> ok
<ChrisL> ok but we need to include an example of that check, in
the spec
heycam: you'd still need to check if there's any path data to
disambiguate between 0,0 due to no path data or do to actually
being 0,0
shepazu: you'd have to add a check either way
... whether that be an exception or whatever
... but it depends what is common practice these days
<nikos> for getPointAtLength it makes sense to me to return 0,0
when there's no path data as that is within the bounding box
<ed> proposal: if you pass a distance longer than the path ->
return the last point on the path, if negative/zero distance ->
return the first point on the path
shepazu: we should put and issue with the rationale in the spec
so that when we go to LC we can get feedback on this
... we could outline both approaches
heycam: I'd be happy with an issue
... I think WebGL or some other API has a tendency for things
to go to NaN
ChrisL: I agree with Doug about putting it in the spec as an
issue
... then we can get feedback
<ChrisL> yes, its fine
heycam: so for the interim shall we go with 0,0?
... plus an issue outline the alternatives and rationale
RESOLUTION: getPointAtLength will return a 0,0 point if there
is no path data and we will add an issue about this to the spec
ed: and when the distance is longer than the path length or
negative then we use the last point / first point on the path
as appropriate
heycam: you clamp the input length value to [0, length of path]
ed: the second method is getPathSegAtLength
... which returns an index to a path segment
... that currently returns an unsigned long in the IDL
krit: Rik would prefer to make it unrestricted double and
return NaN when there is no path data
... I would prefer null
heycam: what about doing something like getPointAtLength where
you clamp the value so you either return 0 or the last path
segment?
(someone): agreed
heycam: krit what do you think?
krit: how does it compare to getPointAtLength?
heycam: it's similar in that you clamp the result at the end of
the existing path
... so you clamp to the first / last segment of the path
... getPointAtLength clamps to the start / end point of the
path
ed: it's only really strange when there is no real first
segment if you want to be able to distinguish that case
heycam: but you can look at pathData.length or whatever it is
to see if there are any actual segments
ed: yeah, that's fine, I'm ok with that
heycam: I think the same arguments apply as well where you
might be doing some calculations and there's some error where
you've gone just past the end of the path
... the calculation shoudn't get corrupted from that
RESOLUTION: getPointAtLength and getPathSegAtLength with clamp
their input to be at the start / end of the path appropriate
and so always return a valid point / path segment index
<scribe> ACTION: Erik to add text for getPointAtLength and
getPathSegAtLength to describe behavior when there is not path
data or when the index/length is beyond the ends of the path
[recorded in
[15]http://www.w3.org/2014/06/26-svg-minutes.html#action02]
<trackbot> Created ACTION-3633 - Add text for getpointatlength
and getpathsegatlength to describe behavior when there is not
path data or when the index/length is beyond the ends of the
path [on Erik Dahlström - due 2014-07-03].
Filter effects and blend modes for feBlend
krit: I was looking into it in WebKit and it was very easy
implement all blend modes for feBlend
... I also checked with Vlad from Mozilla and he suggested it
was easy to do with Moz2D / Direct3D
... I suggest we add all blend modes to SVG
... to unify across canvas/CSS/SVG
heycam: does canvas use different keywords for blend modes to
SVG?
krit: no
heycam: is this for level 2 of filters?
krit: no for the current level
heycam: what is the status of the spec?
krit: there are still issues about filter regions and it still
needs detailed review
... and the animation part needs cleanup
heycam: I'm happy with adding the remaining blend modes now
RESOLUTION: Add all the additional modes specified for the CSS
property to feBlend
<krit> [16]http://dev.w3.org/fxtf/compositing-1/#ltblendmodegt
[16] http://dev.w3.org/fxtf/compositing-1/#ltblendmodegt
heycam: are these the ones in PDF?
ChrisL: so long as the equations are in a W3C spec
heycam: are we adding keywords supported by the property but
not in SVG? or adding keywords to the property?
krit: I'm adding hue, saturate etc. etc. which are already on
the CSS property but not yet supported by feBlend
heycam: does PDF define additional modes?
krit: maybe. And Photoshop have more still
... but initially we wanted to stick with widely-supported
blend modes
<ChrisL> yes
RRSAgent: make minutes please
Summary of Action Items
[NEW] ACTION: Erik to add text for getPointAtLength and
getPathSegAtLength to describe behavior when there is not path
data or when the index/length is beyond the ends of the path
[recorded in
[17]http://www.w3.org/2014/06/26-svg-minutes.html#action02]
[NEW] ACTION: Erik to remove altGlyph and company ffrom SVG2
[recorded in
[18]http://www.w3.org/2014/06/26-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version
1.138 ([20]CVS log)
$Date: 2014-06-26 13:44:55 $
__________________________________________________________
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [21]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/ffrom/from/
Succeeded: s/ index greater than the number of segments in the path/ dis
tance larger than the lenght of the path/
Succeeded: s/proposa/proposal/
Succeeded: s/actually segments/actual segments/
Succeeded: s/should get corrupted/shoudn't get corrupted/
Succeeded: s/might//
Succeeded: s/all the additional blend modes/all the additional modes spe
cified for the CSS property/
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: [IPcaller], ed, heycam, birtles, stakagi, krit, Doug_Sc
hepers, Smailus, ChrisL, Tav
Present: [IPcaller] ed heycam birtles stakagi krit Doug_Schepers Smailus
ChrisL Tav
WARNING: Replacing previous Regrets list. (Old list: Rich)
Use 'Regrets+ ... ' if you meant to add people without replacing the lis
t,
such as: <dbooth> Regrets+ Richard
Regrets: Richard
Agenda: [22]http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun
/0105.html
Found Date: 26 Jun 2014
Guessing minutes URL: [23]http://www.w3.org/2014/06/26-svg-minutes.html
People with action items: erik
[22] http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0105.html
[23] http://www.w3.org/2014/06/26-svg-minutes.html
[End of [24]scribe.perl diagnostic output]
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 26 June 2014 13:50:27 UTC