IRC log of svg on 2014-06-26

Timestamps are in UTC.

12:56:33 [RRSAgent]
RRSAgent has joined #svg
12:56:33 [RRSAgent]
logging to
12:56:35 [trackbot]
RRSAgent, make logs public
12:56:35 [Zakim]
Zakim has joined #svg
12:56:37 [trackbot]
Zakim, this will be GA_SVGWG
12:56:37 [Zakim]
ok, trackbot; I see GA_SVGWG()9:00AM scheduled to start in 4 minutes
12:56:38 [trackbot]
Meeting: SVG Working Group Teleconference
12:56:38 [trackbot]
Date: 26 June 2014
12:56:41 [heycam]
Regrets: Rich
12:56:45 [heycam]
Chair: Cameron
12:56:51 [heycam]
12:57:25 [Zakim]
GA_SVGWG()9:00AM has now started
12:57:32 [Zakim]
12:58:01 [Smailus]
Smailus has joined #svg
12:58:10 [Zakim]
12:58:20 [ed]
Zakim, [IP is me
12:58:20 [Zakim]
+ed; got it
12:58:23 [Zakim]
12:58:25 [heycam]
Zakim, [ is me
12:58:25 [Zakim]
+heycam; got it
12:59:05 [Zakim]
12:59:15 [birtles]
Zakim, [ is me
12:59:15 [Zakim]
+birtles; got it
13:00:43 [Zakim]
13:00:54 [Zakim]
13:00:56 [stakagi]
zakim, ??P6 is me
13:00:56 [Zakim]
+stakagi; got it
13:01:24 [Smailus]
who is on the phone
13:01:32 [heycam]
Zakim, who is on the phone?
13:01:32 [Zakim]
On the phone I see ??P0, ed, heycam, birtles, stakagi, ??P8
13:01:42 [krit]
Zakim, P8 is me
13:01:42 [Zakim]
sorry, krit, I do not recognize a party named 'P8'
13:01:47 [krit]
Zakim, ??P8 is me
13:01:47 [Zakim]
+krit; got it
13:01:57 [Zakim]
13:02:21 [Smailus]
zakim, P0 is me
13:02:22 [Zakim]
sorry, Smailus, I do not recognize a party named 'P0'
13:02:48 [ChrisL]
ChrisL has joined #svg
13:02:53 [heycam]
Zakim, ??P0 is Smailus
13:02:53 [Zakim]
+Smailus; got it
13:03:49 [birtles]
ScribeNick: birtles
13:03:51 [birtles]
Scribe: birtles
13:03:52 [heycam]
Zakim, who is noisy?
13:04:05 [Zakim]
heycam, listening for 10 seconds I heard sound from the following: Smailus (38%), heycam (100%)
13:04:09 [birtles]
Topic: Proposal: Remove altGlyph, altGlyphDef, altGlyphItem and glyphRef from SVG2
13:04:28 [birtles]
ed: I sent to the mailing list tests which I ran on all the different browsers I could find
13:04:28 [ed]
13:04:43 [birtles]
... this test was to verify that altGlyph doesn't work on normal fonts that are not SVG fonts
13:04:48 [birtles]
... I couldn't find any browser that did that
13:05:00 [birtles]
... the only browsers that supported altGlyph only did so for SVG fonts
13:05:09 [birtles]
... so since we're removing SVG fonts it makes sense to remove these as well
13:05:18 [birtles]
heycam: makes sense to me
13:05:24 [birtles]
ed: if you look at the test itself
13:05:34 [birtles]
... I wasn't sure how to reference glyph IDs so I used various ways
13:05:38 [birtles]
... but none of them worked
13:05:42 [Zakim]
13:06:04 [birtles]
heycam: it might have interesting the spec actually said what the syntax was for referencing glyphs from different font formats
13:06:18 [birtles]
ChrisL: I don't think there is an approved way of pointing into a table in a binary font format
13:06:26 [birtles]
... that syntax was only ever intended for SVG fonts
13:06:43 [birtles]
heycam: anyone against removing these from SVG2?
13:06:49 [birtles]
13:07:10 [birtles]
RESOLUTION: We will remove altGlyph and company from SVG2
13:07:23 [ChrisL]
13:07:23 [birtles]
Smailus: I agree
13:07:33 [birtles]
ACTION: Erik to remove altGlyph and company ffrom SVG2
13:07:33 [trackbot]
Created ACTION-3632 - Remove altglyph and company ffrom svg2 [on Erik Dahlström - due 2014-07-03].
13:07:41 [birtles]
13:08:01 [birtles]
Topic: How should the following two SVGPathElement methods work when there's no path data?
13:08:21 [birtles]
ed: I did what we discussed on the last call and posted to the mailing list with various options from the browsers
13:08:25 [ed]
13:08:31 [birtles]
... I listed a bunch of different proposals
13:08:39 [birtles]
... the email thread also had a few more suggestions
13:08:53 [birtles]
... for the first one, getPointAtLength, that returns an SVGPoint
13:09:00 [birtles]
... one suggestion from Dirk was to return undefined
13:09:07 [ed]
13:09:14 [birtles]
krit: or null? does nullable return undefined or null?
13:09:25 [birtles]
heycam: returning undefined is a bit difficult from IDL
13:09:36 [birtles]
... it doesn't really happen in other APIs, generally we return null
13:09:44 [birtles]
... I would suggest that over undefined
13:09:59 [birtles]
ed: would that be stringified to 0... ?
13:10:11 [birtles]
heycam: I would suggest we change the IDL to SVGPoint? so that null can be returned as is
13:10:12 [krit]
13:10:36 [birtles]
ed: so if you're expecting to get an SVGPoint back you'd have to check the return value point for
13:10:44 [birtles]
heycam: sorry, I was referring to the other method
13:11:06 [birtles]
... last time I think we discussed the pros and cons of objects with NaN members vs returning a null value
13:11:28 [birtles]
... if the object has NaN values the code would probably continue further but it might make it harder to track down problems later
13:11:34 [birtles]
... anyone prefer NaN x/y values?
13:11:58 [birtles]
ed: Dirk suggested in the mail that that might be ok
13:12:09 [krit]
I am fine with null or SVGPoint(NaN, NaN)
13:12:18 [birtles]
Smailus: I prefer making something clearly an error
13:12:45 [birtles]
krit: if you search GitHub for these two methods you won't find any results except test cases
13:12:53 [ChrisL]
agree, returning a potentially valid value is suboptimal (even if a second call can disambiguate it)
13:12:56 [birtles]
... to give you an idea how important they are
13:13:27 [birtles]
birtles: I slightly lean towards SVGPoint(NaN, NaN) but null may be ok too
13:13:29 [krit]
13:13:37 [birtles]
heycam: Tab mentioned that there's a similarity with getBoundingBox
13:13:55 [birtles]
... in the end we settled on making getBoundingBox on an empty group return rect(0, 0, 0, 0)
13:14:01 [Zakim]
13:14:12 [birtles]
... but if you called getBoundingBox on a parent of that, that 0 point wouldn't contribute to the parent's bbox
13:14:29 [birtles]
Smailus: so that's an argument for returning 0 to keep things consistent
13:15:02 [birtles]
ChrisL: there's many different things we could be consistent with
13:15:08 [ed]
13:15:15 [birtles]
ed: Tab also mentioned that it's not defined if you use an index greater than the number of segments in the path
13:15:46 [birtles]
heycam: and for getPointAtLength you could use a length greater than the length of the path
13:15:56 [ed]
s/ index greater than the number of segments in the path/ distance larger than the lenght of the path/
13:16:19 [shepazu]
13:16:23 [birtles]
... 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
13:17:08 [birtles]
heycam: I'm inclined for it to be 0,0 if there's no path data
13:17:25 [birtles]
Smailus: I support that
13:17:27 [ChrisL]
13:17:49 [ChrisL]
ok but we need to include an example of that check, in the spec
13:18:23 [birtles]
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
13:18:30 [birtles]
shepazu: you'd have to add a check either way
13:18:41 [birtles]
... whether that be an exception or whatever
13:18:51 [birtles]
... but it depends what is common practice these days
13:19:47 [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
13:19:48 [ed]
proposa: 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
13:19:51 [birtles]
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
13:19:56 [ed]
13:19:57 [birtles]
... we could outline both approaches
13:20:11 [birtles]
heycam: I'd be happy with an issue
13:20:30 [birtles]
... I think WebGL or some other API has a tendency for things to go to NaN
13:20:39 [birtles]
ChrisL: I agree with Doug about putting it in the spec as an issue
13:20:48 [birtles]
... then we can get feedback
13:21:00 [ChrisL]
yes, its fine
13:21:03 [birtles]
heycam: so for the interim shall we go with 0,0?
13:21:10 [birtles]
... plus an issue outline the alternatives and rationale
13:21:26 [ChrisL]
zakim, mute doug
13:21:26 [Zakim]
Doug_Schepers should now be muted
13:21:34 [ChrisL]
zakim, unmute doug
13:21:34 [Zakim]
Doug_Schepers should no longer be muted
13:21:36 [birtles]
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
13:22:00 [birtles]
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
13:22:24 [birtles]
heycam: you clamp the input length value to [0, length of path]
13:23:14 [birtles]
ed: the second method is getPathSegAtLength
13:23:19 [birtles]
... which returns an index to a path segment
13:23:27 [birtles]
... that currently returns an unsigned long in the IDL
13:23:54 [birtles]
krit: Rik would prefer to make it unrestricted double and return NaN when there is no path data
13:24:00 [birtles]
... I would prefer null
13:24:44 [birtles]
heycam: what about doing something like getPointAtLength where you clamp the value so you either return 0 or the last path segment?
13:25:02 [birtles]
(someone): agreed
13:25:34 [birtles]
heycam: krit what do you think?
13:25:43 [birtles]
krit: how does it compare to getPointAtLength?
13:25:52 [birtles]
heycam: it's similar in that you clamp the result at the end of the existing path
13:26:05 [birtles]
... so you clamp to the first / last segment of the path
13:26:14 [birtles]
... getPointAtLength clamps to the start / end point of the path
13:26:28 [birtles]
ed: it's only really strange when there is no real first segment if you want to be able to distinguish that case
13:26:46 [birtles]
heycam: but you can look at pathData.length or whatever it is to see if there are any actually segments
13:26:56 [birtles]
s/actually segments/actual segments/
13:27:01 [birtles]
ed: yeah, that's fine, I'm ok with that
13:27:34 [birtles]
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
13:27:46 [birtles]
... the calculation should get corrupted from that
13:28:14 [birtles]
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
13:28:26 [birtles]
s/should get corrupted/shoudn't get corrupted/
13:28:56 [birtles]
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
13:28:56 [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].
13:29:21 [birtles]
topic: Filter effects and blend modes for feBlend
13:29:38 [birtles]
krit: I was looking into it in WebKit and it was very easy implement all blend modes for feBlend
13:29:57 [birtles]
... I also checked with Vlad from Mozilla and he suggested it was easy to do with Moz2D / Direct3D
13:30:13 [birtles]
... I suggest we add all blend modes to SVG
13:30:24 [birtles]
... to unify across canvas/CSS/SVG
13:31:22 [birtles]
heycam: does canvas use different keywords for blend modes to SVG?
13:31:24 [birtles]
krit: no
13:31:37 [birtles]
heycam: is this for level 2 of filters?
13:31:42 [birtles]
krit: no for the current level
13:31:47 [birtles]
heycam: what is the status of the spec?
13:32:00 [birtles]
krit: there are still issues about filter regions and it still needs detailed review
13:32:05 [birtles]
... and the animation part needs cleanup
13:32:20 [birtles]
heycam: I'm happy with adding the remaining blend modes now
13:33:18 [birtles]
RESOLUTION: Add all the additional blend modes to feBlend
13:33:19 [krit]
13:33:24 [birtles]
heycam: are these the ones in PDF?
13:33:37 [birtles]
ChrisL: so long as the equations are in a W3C spec
13:34:07 [birtles]
heycam: are we adding keywords supported by the property but not in SVG? or adding keywords to the property?
13:34:28 [birtles]
krit: I'm adding hue, saturate etc. etc. which are already on the CSS property but not yet supported by feBlend
13:34:39 [birtles]
heycam: does PDF define additional modes?
13:34:47 [birtles]
krit: maybe. And Photoshop might have more still
13:34:55 [birtles]
... but initially we wanted to stick with widely-supported blend modes
13:35:07 [krit]
13:35:31 [birtles]
s/all the additional blend modes/all the additional modes specified for the CSS property/
13:35:55 [Zakim]
13:36:36 [Zakim]
13:39:38 [ChrisL]
13:40:46 [birtles]
Regrets: Richard
13:44:29 [Zakim]
13:44:30 [Zakim]
13:44:30 [Zakim]
13:44:31 [Zakim]
13:44:32 [Zakim]
13:44:33 [Zakim]
13:44:33 [Zakim]
13:44:34 [Zakim]
13:44:43 [Zakim]
13:44:44 [Zakim]
GA_SVGWG()9:00AM has ended
13:44:44 [Zakim]
Attendees were [IPcaller], ed, heycam, birtles, stakagi, krit, Doug_Schepers, Smailus, ChrisL, Tav
13:44:50 [birtles]
RRSAgent: make minutes please
13:44:50 [RRSAgent]
I have made the request to generate birtles
13:44:56 [Zakim]
GA_SVGWG()9:00AM has now started
13:45:03 [Zakim]
13:45:14 [Zakim]
13:45:15 [Zakim]
GA_SVGWG()9:00AM has ended
13:45:15 [Zakim]
Attendees were
15:30:02 [Zakim]
Zakim has left #svg
15:43:55 [ed]
heycam|away: just pushed changes to, and the push to seems to have failed... wrong ssh keys?
15:44:25 [ed]
or maybe it's just the fingerprint that changed
15:44:49 [ed]
remote: pushing to
15:44:49 [ed]
remote: warning: certificate with fingerprint 14:a5:f7:99:95:f8:41:9b:02:71:2c:4b:87:d2:e0:8b:f2:cf:4b:a3 not verified (check hostfingerprints or web.cacerts config setting)
15:45:02 [ed]
remote: abort: authorization failed
15:45:02 [ed]
remote: FAIL: error syncing - inform jwatt or heycam ASAP!
15:45:02 [ed]
remote: warning: changegroup.sync_dvcs_w3_org hook failed