20:27:24 <RRSAgent> RRSAgent has joined #svg
20:27:24 <RRSAgent> logging to http://www.w3.org/2013/08/29-svg-irc
20:27:26 <trackbot> RRSAgent, make logs public
20:27:26 <Zakim> Zakim has joined #svg
20:27:28 <trackbot> Zakim, this will be GA_SVGWG
20:27:28 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)4:30PM scheduled to start in 3 minutes
20:27:29 <trackbot> Meeting: SVG Working Group Teleconference
20:27:29 <trackbot> Date: 29 August 2013
20:28:09 <Zakim> GA_SVGWG(SVG1)4:30PM has now started
20:28:16 <Zakim> +[IPcaller]
20:28:23 <heycam> Regrets: Rik
20:28:29 <ed> Zakim, [IP is me
20:28:29 <Zakim> +ed; got it
20:28:52 <Zakim> +??P3
20:28:54 <heycam> Zakim, ??P3 is me
20:28:54 <Zakim> +heycam; got it
20:29:21 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0071.html
20:30:13 <Zakim> + +49.341.263.2.aaaa
20:30:43 <krit1> Zakim, aaaa is me
20:30:43 <Zakim> +krit1; got it
20:31:06 <krit> Zakim, krit1 is me
20:31:07 <Zakim> + +33.6.48.38.aabb
20:31:07 <Zakim> +krit; got it
20:31:24 <Zakim> +??P14
20:31:51 <cyril> Zakim, P14 is me
20:31:51 <Zakim> sorry, cyril, I do not recognize a party named 'P14'
20:31:58 <cyril> Zakim, +??P14 is me
20:31:58 <Zakim> sorry, cyril, I do not recognize a party named '+??P14'
20:32:05 <cyril> Zakim, ??P14 is me
20:32:05 <Zakim> +cyril; got it
20:32:24 <heycam> Zakim, who is on the call?
20:32:24 <Zakim> On the phone I see ed, heycam, krit, +33.6.48.38.aabb, cyril
20:33:08 <Luc> Luc has joined #svg
20:33:19 <heycam> Scribe: Cameron
20:33:21 <ed> Zakim, +33 is luc
20:33:21 <Zakim> +luc; got it
20:33:21 <heycam> Chair: Erik
20:33:25 <heycam> ScribeNick: heycam
20:33:40 <heycam> Topic: response to css-fonts-3 comments
20:34:12 <Zakim> + +61.2.980.5.aacc
20:34:22 <nikos> Zakim, +61.2 is me
20:34:22 <Zakim> +nikos; got it
20:34:25 <heycam> http://lists.w3.org/Archives/Public/www-style/2013Aug/0477.html
20:34:33 <heycam> CM: got this reponse tfrom John Daggett
20:35:35 <heycam> CM: I will reply today asking for more detail on the test files
20:35:44 <heycam> Topic: initial color for drop shadow
20:35:49 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterProperty
20:35:56 <heycam> krit: we have a drop shadow filter function
20:36:07 <heycam> … we have a default color value
20:36:14 <heycam> … we don't have a fallback color
20:36:23 <heycam> … I suggest using the same as box-shadow
20:36:28 <heycam> … i.e. the current used value of the color property
20:36:43 <heycam> heycam: is that the same for text-shadow and box-shadow?
20:36:43 <heycam> krit: yes
20:36:58 <heycam> heycam: sounds reasonable to me
20:37:02 <heycam> ed: to me too
20:37:12 <heycam> … this only applies if you don't specify the color in the drop-shadow syntax right?
20:37:13 <heycam> krit: yes
20:37:15 <heycam> ed: fine with me then
20:37:26 <heycam> RESOLVED: drop-shadow will use the computed value of 'color' property if no shadow color is specified
20:37:32 <heycam> s/RESOLVED/RESOLUTION/
20:37:42 <heycam> Topic: adding edge mode to feGaussianBlur
20:37:45 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue
20:37:55 <heycam> krit: for context, I implemented the CSS image function for WebKit
20:38:36 <krit> background-image: filter(url(image.png), blur(10px));
20:39:02 <heycam> krit: if you specify blur, then the image gets blurred
20:39:10 <heycam> … but on the edges, it takes from transparent black
20:39:15 <heycam> … you get a fading effect at the edges
20:39:22 <heycam> … the problem is that the dimensions of the image must not change
20:39:29 <heycam> … so you clip right in the middle of the fading effect
20:39:31 <heycam> … and it looks ugly
20:39:46 <heycam> … my question is whether we can edgeMode that we have on convolution matrix
20:39:51 <heycam> … which specifies the edge behaviour you want
20:40:08 <heycam> … it has three different values: you can take the same colour at the edge
20:40:17 <heycam> … another is that you walk to the opposite side's pixel (good for repeating patterns)
20:40:53 <heycam> … I'd suggest for the filter() function that we use the edgeMode="duplicate", which takes the takes the colour at the edge and repeats it
20:40:58 <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementEdgeModeAttribute
20:40:59 <heycam> … this gives the most reasonable result
20:41:22 <heycam> … there is an example where we apply different blurs and a convolution matrix
20:41:30 <heycam> … what do you think?
20:41:35 <Thomas_Smailus> Thomas_Smailus has joined #svg
20:42:08 <Zakim> + +1.425.373.aadd
20:42:11 <heycam> heycam: don't you just want to inflate the rectangle that clips the background image?
20:42:21 <heycam> krit: this would modify the origin of the background image
20:42:28 <heycam> … if you increase the area, then the image would shift
20:43:47 <heycam> heycam: maybe it's too much of a special case
20:43:53 <heycam> krit: it wouldn't work if you had a repeated background image
20:44:37 <heycam> krit: I'd like to add edgeMode="" to <feGaussianBlur>
20:44:44 <heycam> … for the shorthand function I suggest it be fixed
20:44:51 <heycam> s/be/to be/
20:45:08 <heycam> … fixed to be "duplicate", when used in a filter() image
20:45:17 <heycam> … we could add an argument later if it's needed
20:45:45 <heycam> ed: I'm wondering about the feGaussianBlur case
20:45:51 <heycam> … you can have repeated tiles only when you use feTile, right?
20:45:53 <heycam> krit: yes
20:46:00 <heycam> ed: so that doesn't support edgeMode="" either
20:46:11 <heycam> krit: with feGuassianBlur, you might not want the edge blurred
20:46:15 <heycam> … but it also effects things like feTile
20:46:25 <heycam> s/feGuassianBlur/feGaussianBlur/
20:47:35 <heycam> heycam: do this apply to 'blur'?
20:47:37 <heycam> krit: just to blur
20:48:00 <heycam> heycam: there aren't any other filter primitives that sample outside the image?
20:48:18 <heycam> krit: blur and drop-shadow can extend the image
20:48:34 <heycam> … for blur the use case is that you don't want the edge fading effect cut off
20:48:48 <heycam> … the other filter primitives are just color manipulations
20:50:20 <heycam> heycam: but drop-shadow doesn't sample pixels outside the original image?
20:50:21 <heycam> krit: right
20:50:38 <heycam> ed: do we add this now, later, or just at feGaussianBlur?
20:50:42 <heycam> krit: one option is to not care about it at all
20:50:51 <heycam> … second option is to have special behaviour for filter functions
20:51:19 <heycam> … third option is have edgeMode="" on <feGaussianBlur>, and still have special behaviour for filter functions
20:52:28 <heycam> heycam: we don't have to special case 'blur', just say that if any filter primitive sampled outside the original image, it uses the edgeMode="duplicate" behaviour
20:53:23 <heycam> ed: I'm wondering about the syntax, what would you put in the shorthand syntax?
20:53:30 <heycam> … new parameter?  new property?
20:53:40 <heycam> krit: so far I'm still suggesting to fix it to "duplicate"
20:53:48 <heycam> … but later we could add a new keyword next to 'blur'
20:54:05 <heycam> ed: no objections to this right now
20:54:12 <heycam> krit: we can review it later if we need to
20:54:43 <krit> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-conv-01-f.html
20:54:52 <heycam> ACTION: Dirk to edit FIlter spec to make edgeMode="duplicate" behaviour the default for filter() image functions
20:54:52 <trackbot> Created ACTION-3521 - Edit filter spec to make edgemode="duplicate" behaviour the default for filter() image functions [on Dirk Schulze - due 2013-09-05].
20:56:17 <heycam> RESOLUTION: filter() image functions use edgeMode="duplicate" behaviour for sampling outside source image
20:56:35 <heycam> Topic: negative standard deviation on feGaussianBlur
20:56:43 <heycam> krit: I noticed that we have no special case for negative values
20:56:49 <heycam> … implementations agree that we don't support them
20:57:01 <heycam> … I think that makes sense. for a negative value you either take the absolute value, or define what else happens
20:57:53 <heycam> … an error state or as zero
20:58:03 <heycam> heycam: we could treat it as if you didn't specify it
20:58:11 <heycam> krit: Lacuna value is actually zero
20:58:21 <heycam> ed: the equations specify what happens for negative values, but we decided not to allow it
20:58:33 <heycam> … the stdDeviation values are squared anyway, so it would work
20:58:40 <heycam> … so a minus value would be the same result as the positive value
20:58:47 <heycam> … I think the spec right now says it's in error
20:58:49 <heycam> krit: it doesn't
20:59:02 <heycam> … for squaring, it's true for real gaussian blur, but not for the approximation
20:59:27 <heycam> ed: I was sure we had negative value handling in the spec, but maybe we don't
20:59:44 <heycam> krit: I just added "A negative value or a value of zero disables the effect of the given filter primitive (i.e., the result is the filter input image)."
21:00:21 <heycam> krit: so that's fine, keep it?
21:00:22 <heycam> heycam: yep
21:00:38 <heycam> ed: that's what implementations do?
21:00:49 <heycam> krit: yes. though I think Firefox disables rendering of the element.
21:00:52 <heycam> heycam: file a bug!
21:01:04 <heycam> RESOLUTION: Keep current negative stdDeviation value handling that's in the spec.
21:01:31 <heycam> Topic: high dpi filters on convolution and lighting
21:01:38 <heycam> krit: gaussian blur and lighting are highly resolution dependent
21:01:51 <heycam> … you could simulate with your normal screen if you zoom in
21:01:55 <heycam> … you can see the rendered result doesn't scale
21:02:02 <krit> http://www.w3.org/Graphics/SVG/Test/20110816/svg/filters-conv-01-f.svg
21:02:15 <heycam> … if you resize the window, you see the result looks different
21:02:40 <heycam> … is this the desired effect?
21:02:55 <heycam> … do we accept that the results are resolution dependent?
21:03:08 <heycam> … we have filterRes="" to make things look the same on all devices, but people don't use that
21:03:23 <heycam> … (and kernelUnitLength="")
21:03:48 <heycam> … filterRes="" affects the whole filter chain, kernelUnitLength="" is just for the convolution primitive
21:04:10 <heycam> … scaling the kernel unit length automatically could result in different behaviour
21:04:16 <heycam> … I think kernel scaling is not a possibility
21:05:04 <heycam> heycam: I would be worried that authors are expecting convolutions etc. to be acting on specific bitmap image
21:05:09 <heycam> … and scaling could change the result
21:05:26 <heycam> krit: this issue comes up with hidpi displays
21:05:32 <heycam> … but it existed before, with zooming
21:05:41 <heycam> … we already decided to remove filterRes=""
21:05:51 <heycam> … but you can still use kernelUnitLength=""
21:06:07 <heycam> … I checked various examples on the Web, didn't find uses of these attributes with convolution matrices or lighting effects
21:06:34 <heycam> … kernelUnitLength="" doesn't really help the author; it's dependent on the object size
21:06:47 <heycam> … to apply the filter to a specific object you need to know the size of the object
21:06:52 <heycam> … which reduces reusability of filters
21:07:03 <heycam> … (the object could be text, shapes, etc.)
21:07:19 <heycam> ed: how common did you find the use of convolution matrices?
21:07:30 <heycam> krit: I found a lot of tutorials, examples
21:07:35 <heycam> … where the kernel didn't really matter
21:07:42 <heycam> … e.g. a 3x3 matrix that just did a blur
21:08:00 <heycam> ed: my personal experience is that it's not very common
21:08:18 <heycam> krit: so what do we want to do?
21:08:25 <heycam> … we could say that these filters are highly dependent on the resolution
21:08:33 <heycam> … this might be fine for convolution matrices, but not great for lighting filters
21:08:37 <heycam> … they're used for bump maps
21:09:27 <heycam> … we could scale the image ourselves, we know the local space to screen coord space
21:09:37 <heycam> … we could say how much 1 CSS px scales to the screen
21:09:52 <heycam> … so we could have a convolution matrix / lighting that is independent of the platform
21:10:08 <heycam> … but since 1 CSS px doesn't match 1 device pixel, if you scaling things you'll lose quality
21:10:27 <heycam> … you could pixellate, or bilinear interpolate, ...
21:10:35 <heycam> … might look reasonable, might look very bad
21:10:41 <heycam> … but at least they would be the same across platforms
21:11:15 <heycam> … my suggestion is that we preserve the current mode, device dependent results, but allow the user to specify that it scales so that it is platform independent (possibly with a loss of quality)
21:11:23 <Zakim> -luc
21:11:36 <heycam> ed: how about must at least match CSS pixels, but implementations are allowed to match device pixels?
21:11:43 <heycam> krit: how would the author control that? at all?
21:11:54 <heycam> ed: we already have a quality hint
21:12:02 <heycam> … maybe there's not one for filters?
21:12:10 <heycam> krit: we could say that image-rendering could affect the result of filters
21:12:30 <heycam> ed: we should try to compute reasonable values on behalf of the user
21:13:01 <heycam> krit: I don't care how we do it -- a new attribute, or hints from other properties -- but maybe not implement kernelUnitLength at all
21:13:20 <heycam> heycam: so convolution matrices always have to be a specific size?
21:14:58 <heycam> krit: it doen'st affect the convolution matrix
21:15:02 <heycam> … it scales the input to the kernel
21:15:19 <heycam> … but kernelUnitLength always makes things look bad, if device independent
21:15:26 <heycam> … so I'm suggesting using either CSS px or device px everywhere
21:15:31 <heycam> … and not have kernelUnitLength
21:15:58 <heycam> heycam: so Blink/WebKit doesn't implement kernelUnitLength currently?
21:15:59 <heycam> krit: right
21:16:20 <heycam> … it's implemented in Firefox, Batik, possibly in ASV
21:16:22 <heycam> ed: Presto had it too
21:16:44 <heycam> heycam: what was the view on the mailing list?
21:17:06 <heycam> krit: one implementer in a new UA agreed kernelUnitLength is not useful
21:17:19 <heycam> … ddailey suggested lack of usage could be due to lack of implementation
21:17:27 <heycam> … but I don't think that addresses the concerns with kernelUnitLength
21:18:16 <heycam> krit: so I propose to remove kernelUnitLength="", either add a new attribute to select between matching to CSS px or device px, or use one of the existing properties
21:18:21 <heycam> … I'd prefer a new attribute
21:18:24 <heycam> … I can work out a proposal
21:19:16 <heycam> ACTION: Dirk to propose an attribute to control convolution/lighting kernel size working on CSS or device pixels
21:19:16 <trackbot> Created ACTION-3522 - Propose an attribute to control convolution/lighting kernel size working on css or device pixels [on Dirk Schulze - due 2013-09-05].
21:19:54 <heycam> Topic: url() passed through on invalid reference
21:20:01 <heycam> krit: right now you can use url() to reference an SVG filter
21:20:15 <heycam> … if the filter doesn't exist, or is not loaded, the whole filter chain is in an error state and we don't render the element at all
21:20:30 <heycam> … so if you specify a 'filter' property with an invalid url, the whole element doesn't get rendered
21:20:41 <heycam> … with filter functions, I don't think it's useful
21:20:54 <heycam> … if we have an invalid url, we should treat it as a passthrough filter
21:21:18 <heycam> … it's easier for the author to see that something is not working -- you also see it if it's not rendered at all, but I think that's more confusing
21:21:33 <heycam> … if you have two url() functions in a chain, the second would get a null image input
21:21:39 <heycam> … and applies its own filters to this null image
21:22:04 <heycam> … either way it's not the desired result of the author
21:22:39 <heycam> … but I think it's easier for the author to see what's happening, and for the viewer
21:22:46 <heycam> … this has no effect on the screen reader btw
21:22:57 <Zakim> -cyril
21:23:09 <heycam> ed: so you want it to be a pass through, rather than breaking the entire chain, using no filter at all?
21:23:12 <heycam> krit: that's another option
21:23:15 <heycam> … not applying the filter at all
21:23:25 <heycam> ed: if you have a chain of filter, presumably you want the entire thing
21:23:35 <heycam> … I can see sometimes you might want the pass through
21:23:42 <heycam> … either of those options
21:23:46 <heycam> krit: which would you prefer?
21:24:03 <heycam> ed: I guess it depends on how it's used
21:25:04 <heycam> heycam: I feel like there's more chance of the reader being able to read the content if you don't apply the entire filter chain
21:26:00 <heycam> … because leaving out one filter primitive could leave you in a state where the content is not readable
21:26:09 <heycam> ed: it depends how you're constructing your examples
21:26:39 <heycam> … might be cases where you're applying it to a duplicated part of the page where you don't want it to show at all
21:26:44 <heycam> … I could see it either way
21:27:03 <thorton> thorton has joined #svg
21:27:49 <heycam> heycam: maybe that case wouldn't come up that often, since you'd do the duplication in the filter itself
21:28:31 <heycam> ed: sounds like ignoring the whole chain has the most support
21:28:55 <heycam> RESOLUTION: An invalid url() in a filter chain causes the entire filter chain not to be applied.
21:29:30 <Zakim> - +1.425.373.aadd
21:29:32 <Zakim> -ed
21:29:33 <Zakim> -heycam
21:29:37 <Zakim> -nikos
21:30:02 <Zakim> -krit
21:30:03 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:30:03 <Zakim> Attendees were [IPcaller], ed, heycam, +49.341.263.2.aaaa, +33.6.48.38.aabb, krit, cyril, luc, +61.2.980.5.aacc, nikos, +1.425.373.aadd
21:30:10 <heycam> RRSAgent, make minutes
21:30:10 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/29-svg-minutes.html heycam
21:37:29 <thorton> thorton has joined #svg
22:45:07 <birtles> birtles has joined #svg