SVG Working Group Teleconference -- 29 Aug 2013

<trackbot> Date: 29 August 2013

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

response to css-fonts-3 comments

http://lists.w3.org/Archives/Public/www-style/2013Aug/0477.html

CM: got this reponse tfrom John Daggett
... I will reply today asking for more detail on the test files

initial color for drop shadow

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterProperty

krit: we have a drop shadow filter function

… we have a default color value

… we don't have a fallback color

… I suggest using the same as box-shadow

… i.e. the current used value of the color property

heycam: is that the same for text-shadow and box-shadow?

krit: yes

heycam: sounds reasonable to me

ed: to me too

… this only applies if you don't specify the color in the drop-shadow syntax right?

krit: yes

ed: fine with me then

RESOLUTION: drop-shadow will use the computed value of 'color' property if no shadow color is specified

adding edge mode to feGaussianBlur

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue

krit: for context, I implemented the CSS image function for WebKit

<krit> background-image: filter(url(image.png), blur(10px));

krit: if you specify blur, then the image gets blurred

… but on the edges, it takes from transparent black

… you get a fading effect at the edges

… the problem is that the dimensions of the image must not change

… so you clip right in the middle of the fading effect

… and it looks ugly

… my question is whether we can edgeMode that we have on convolution matrix

… which specifies the edge behaviour you want

… it has three different values: you can take the same colour at the edge

… another is that you walk to the opposite side's pixel (good for repeating patterns)

… 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

<ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementEdgeModeAttribute

… this gives the most reasonable result

… there is an example where we apply different blurs and a convolution matrix

… what do you think?

heycam: don't you just want to inflate the rectangle that clips the background image?

krit: this would modify the origin of the background image

… if you increase the area, then the image would shift

heycam: maybe it's too much of a special case

krit: it wouldn't work if you had a repeated background image
... I'd like to add edgeMode="" to <feGaussianBlur>

… for the shorthand function I suggest it to be fixed

… fixed to be "duplicate", when used in a filter() image

… we could add an argument later if it's needed

ed: I'm wondering about the feGaussianBlur case

… you can have repeated tiles only when you use feTile, right?

krit: yes

ed: so that doesn't support edgeMode="" either

krit: with feGaussianBlur, you might not want the edge blurred

… but it also effects things like feTile

heycam: do this apply to 'blur'?

krit: just to blur

heycam: there aren't any other filter primitives that sample outside the image?

krit: blur and drop-shadow can extend the image

… for blur the use case is that you don't want the edge fading effect cut off

… the other filter primitives are just color manipulations

heycam: but drop-shadow doesn't sample pixels outside the original image?

krit: right

ed: do we add this now, later, or just at feGaussianBlur?

krit: one option is to not care about it at all

… second option is to have special behaviour for filter functions

… third option is have edgeMode="" on <feGaussianBlur>, and still have special behaviour for filter functions

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

ed: I'm wondering about the syntax, what would you put in the shorthand syntax?

<scribe> … new parameter? new property?

krit: so far I'm still suggesting to fix it to "duplicate"

… but later we could add a new keyword next to 'blur'

ed: no objections to this right now

krit: we can review it later if we need to

<krit> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-conv-01-f.html

<scribe> ACTION: Dirk to edit FIlter spec to make edgeMode="duplicate" behaviour the default for filter() image functions [recorded in http://www.w3.org/2013/08/29-svg-minutes.html#action01]

<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].

RESOLUTION: filter() image functions use edgeMode="duplicate" behaviour for sampling outside source image

negative standard deviation on feGaussianBlur

krit: I noticed that we have no special case for negative values

… implementations agree that we don't support them

… I think that makes sense. for a negative value you either take the absolute value, or define what else happens

… an error state or as zero

heycam: we could treat it as if you didn't specify it

krit: Lacuna value is actually zero

ed: the equations specify what happens for negative values, but we decided not to allow it

… the stdDeviation values are squared anyway, so it would work

… so a minus value would be the same result as the positive value

… I think the spec right now says it's in error

krit: it doesn't

… for squaring, it's true for real gaussian blur, but not for the approximation

ed: I was sure we had negative value handling in the spec, but maybe we don't

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)."
... so that's fine, keep it?

heycam: yep

ed: that's what implementations do?

krit: yes. though I think Firefox disables rendering of the element.

heycam: file a bug!

RESOLUTION: Keep current negative stdDeviation value handling that's in the spec.

high dpi filters on convolution and lighting

krit: gaussian blur and lighting are highly resolution dependent

… you could simulate with your normal screen if you zoom in

… you can see the rendered result doesn't scale

<krit> http://www.w3.org/Graphics/SVG/Test/20110816/svg/filters-conv-01-f.svg

… if you resize the window, you see the result looks different

… is this the desired effect?

… do we accept that the results are resolution dependent?

… we have filterRes="" to make things look the same on all devices, but people don't use that

… (and kernelUnitLength="")

… filterRes="" affects the whole filter chain, kernelUnitLength="" is just for the convolution primitive

… scaling the kernel unit length automatically could result in different behaviour

… I think kernel scaling is not a possibility

heycam: I would be worried that authors are expecting convolutions etc. to be acting on specific bitmap image

… and scaling could change the result

krit: this issue comes up with hidpi displays

… but it existed before, with zooming

… we already decided to remove filterRes=""

… but you can still use kernelUnitLength=""

… I checked various examples on the Web, didn't find uses of these attributes with convolution matrices or lighting effects

… kernelUnitLength="" doesn't really help the author; it's dependent on the object size

… to apply the filter to a specific object you need to know the size of the object

… which reduces reusability of filters

… (the object could be text, shapes, etc.)

ed: how common did you find the use of convolution matrices?

krit: I found a lot of tutorials, examples

… where the kernel didn't really matter

… e.g. a 3x3 matrix that just did a blur

ed: my personal experience is that it's not very common

krit: so what do we want to do?

… we could say that these filters are highly dependent on the resolution

… this might be fine for convolution matrices, but not great for lighting filters

… they're used for bump maps

… we could scale the image ourselves, we know the local space to screen coord space

… we could say how much 1 CSS px scales to the screen

… so we could have a convolution matrix / lighting that is independent of the platform

… but since 1 CSS px doesn't match 1 device pixel, if you scaling things you'll lose quality

… you could pixellate, or bilinear interpolate, ...

… might look reasonable, might look very bad

… but at least they would be the same across platforms

… 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)

ed: how about must at least match CSS pixels, but implementations are allowed to match device pixels?

krit: how would the author control that? at all?

ed: we already have a quality hint

… maybe there's not one for filters?

krit: we could say that image-rendering could affect the result of filters

ed: we should try to compute reasonable values on behalf of the user

krit: I don't care how we do it -- a new attribute, or hints from other properties -- but maybe not implement kernelUnitLength at all

heycam: so convolution matrices always have to be a specific size?

krit: it doen'st affect the convolution matrix

… it scales the input to the kernel

… but kernelUnitLength always makes things look bad, if device independent

… so I'm suggesting using either CSS px or device px everywhere

… and not have kernelUnitLength

heycam: so Blink/WebKit doesn't implement kernelUnitLength currently?

krit: right

… it's implemented in Firefox, Batik, possibly in ASV

ed: Presto had it too

heycam: what was the view on the mailing list?

krit: one implementer in a new UA agreed kernelUnitLength is not useful

… ddailey suggested lack of usage could be due to lack of implementation

… but I don't think that addresses the concerns with kernelUnitLength

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

… I'd prefer a new attribute

… I can work out a proposal

<scribe> ACTION: Dirk to propose an attribute to control convolution/lighting kernel size working on CSS or device pixels [recorded in http://www.w3.org/2013/08/29-svg-minutes.html#action02]

<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].

url() passed through on invalid reference

krit: right now you can use url() to reference an SVG filter

… 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

… so if you specify a 'filter' property with an invalid url, the whole element doesn't get rendered

… with filter functions, I don't think it's useful

… if we have an invalid url, we should treat it as a passthrough filter

… 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

… if you have two url() functions in a chain, the second would get a null image input

… and applies its own filters to this null image

… either way it's not the desired result of the author

… but I think it's easier for the author to see what's happening, and for the viewer

… this has no effect on the screen reader btw

ed: so you want it to be a pass through, rather than breaking the entire chain, using no filter at all?

krit: that's another option

… not applying the filter at all

ed: if you have a chain of filter, presumably you want the entire thing

… I can see sometimes you might want the pass through

… either of those options

krit: which would you prefer?

ed: I guess it depends on how it's used

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

… because leaving out one filter primitive could leave you in a state where the content is not readable

ed: it depends how you're constructing your examples

… 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

… I could see it either way

heycam: maybe that case wouldn't come up that often, since you'd do the duplication in the filter itself

ed: sounds like ignoring the whole chain has the most support

RESOLUTION: An invalid url() in a filter chain causes the entire filter chain not to be applied.

- DRAFT -

SVG Working Group Teleconference

29 Aug 2013

Attendees

Contents

response to css-fonts-3 comments

initial color for drop shadow

adding edge mode to feGaussianBlur

negative standard deviation on feGaussianBlur

high dpi filters on convolution and lighting

url() passed through on invalid reference

Summary of Action Items

Scribe.perl diagnostic output