See also: IRC log
<trackbot> Date: 26 June 2014
<Smailus> who is on the phone
<scribe> ScribeNick: birtles
<scribe> Scribe: birtles
ed: I sent to the mailing list tests which I ran on all the different browsers I could find
<ed> 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 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].
ed: I did what we discussed on the last call and posted to the mailing list with various options from the browsers
<ed> 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> 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> 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> 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 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].
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> 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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/ distance 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 specified for the CSS property/ Found ScribeNick: birtles Found Scribe: birtles Inferring ScribeNick: birtles Default Present: [IPcaller], ed, heycam, birtles, stakagi, krit, Doug_Schepers, 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 list, such as: <dbooth> Regrets+ Richard Regrets: Richard Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0105.html Found Date: 26 Jun 2014 Guessing minutes URL: http://www.w3.org/2014/06/26-svg-minutes.html People with action items: erik[End of scribe.perl diagnostic output]