Fabric.js: Handling Shadow of flipped objects

[panthar1]

Hi, I just wanted to report that this exact same issue as Shadow in SVG is displaying in wrong location when the object is rotated #2669, but with how it works with text shadows. I pasted the SVG below that fabric.js gives me. When compared to rsvg, or even the web browser rendering of the SVG, the shadow that fabric.js displays is on the wrong side of the individual characters. This problem applies to both the X and Y offsets when the text is rotated.

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="300" height="300" viewBox="0 0 300 300" xml:space="preserve">
<desc>Created with Fabric.js 1.6.0-rc.1</desc>
<defs></defs>
<filter id="SVGID_5" y="-20%" height="140%" x="-21%" width="142%" >
    <feGaussianBlur in="SourceAlpha" stdDeviation="0"></feGaussianBlur>
    <feOffset dx="10" dy="0" result="oBlur" ></feOffset>
    <feFlood flood-color="rgb(0, 0, 0)"/>
    <feComposite in2="oBlur" operator="in" />
    <feMerge>
        <feMergeNode></feMergeNode>
        <feMergeNode in="SourceGraphic"></feMergeNode>
    </feMerge>
</filter>
    <g transform="translate(459.5 136.23) scale(1.01 1) matrix(-1 0 0 1 0 0) ">
        <text font-family="Times New Roman" font-size="142" font-weight="normal" style="stroke: none; stroke-width: 0; stroke-dasharray: none; stroke-linecap: butt; stroke-linejoin: miter; stroke-miterlimit: 10; fill: #00ff00; fill-rule: nonzero; opacity: 1;filter: url(#SVGID_5);" >
            <tspan x="-449.5" y="44.73" fill="#00ff00">Some Test Text</tspan>
        </text>
    </g>
</svg>

[asturur]

Do you think is worth mentioning that your text is flipped?
I think the bug applies to any flipped object, text or shadow.

[panthar1]

Sorry, I guess flipped would be the correct word. That's why I included the SVG so you could see the error very easily.

[asturur]

And now the question... should i flip the shadow on canvas or on the SVG?

Let's talk cleary. Shadow should not scale with object, but we did it because it feels more in line with the scaling effect opposite the resize effect.
So in this way flipping a shadow would be ok.

So let's try a new git hub feature, express your emotion on following posts

[asturur]

I will flip the shadow on the canvas when the object flip (THIS IS B)

[asturur]

i will fix the SVG export to do not flip shadow with object, shadow will not flip ( THIS IS A )

[asturur]

@kangax @kienz at least you have to vote. :p

[kangax]

Twitterverse suggested to not flip since changing source of light feels wrong https://twitter.com/kangax/status/708383962834595840

[asturur]

Completely true, but also scaling shadow is wrong and also borders dropping shadows over the mainshape feels wrong.

Just because flipping is a negative scaling i made this question.

[StephanBijzitter]

Scaling shadow can be explained by raising the distance of the object to the surface. Although that's definitely not the case here, it still could be.

I would say the shadows are based on 0-* light source(s) defined by the user/programmer. Give them an x, y and z value and you're good to go.

[asturur]

ok for fixing svg export then.

[panthar1]

Hey Guys,

As someone who is not quite a fabric.js dev, (yet), I would only say the objective of my fun little project is to have a perfect SVG export in every way possible. I am less interested in how it's done, just that what I see on fabric's canvas, I want to look the same in a SVG viewer/browser. So, my 2-cents are, just change the SVG export so things line up wherever possible. This would apply to some of the other issues I have brought up before now to, like with strokes and such. It's not really so much an issue with fabric, as it is, trying to make the SVG export look the same.

[asturur]

yes fix svg export is the purpouse of this topic.
But you can fix in two way, we are jsut choosing wich one.

[panthar1]

I know, that's why I injected my opinion that fixing the SVG is probably better :)