Improve the selection of shading logic for linear gradients

[ganomi]

@rototor in the other PR you pointed at the Tux example, which motivated me to take a look at that.

I have no deep understanding about the vector mathematics involved here, but i believe Tux is not painted perfectly, because linearGradientObjectBoundingBoxShading was just called in too many cases, even on gradients that were explicitly set to userSpaceOnUse in the svg.

When deactivating the code branch for objectBoundingBox, Tux was already painting perfectly in PDF. But of course that broke the test for long-gradient.svg.

So i believe the main problem is, that we are using a heuristic to select the proper shading procedure. Unfortunately the explicit information about the gradientUnits is not available anymore. (The last time i see it explicitly in the stack is in method org.apache.batik.bridge.SVGLinearGradientElementBridge#buildGradient)

So in this PR i propose to fine tune the heuristic by detecting if the coordinate system used is in the range 0 to 1. All common examples use this range because it kind of makes sense for objectBoundingBox.

I would be happy to hear what others think about this, because it sounds like a naive idea. But nothing better came to my mind while thinking about the problem.

[rototor]

Wow, nice. I just released pdfbox-graphics2d version 0.46 and 3.0.4 with your other fix.

I'll have to take a look here.

[rototor]

Hmm, can you show a screenshot (PDF/expected PNG side by side) of what your change should fix?

For me, it seems nothing changed with your changes here:

[ganomi]

Here is a PDF comparison before and after my changes:

[rototor]

Yeah, that looks fine now... I was fooled by the macOS preview app - that stopped to correctly render transparency years ago... Acrobat correctly displays the now working transparencies.

Thank you very much! Lets see if somebody finds another way to break that heuristic. But for now, I'm happy that you found a solution!

[rototor]

I've just released version 0.47 and 3.0.5 with your fix.

[ganomi]

Thank you.

For me there are two remaining questions:

1. What might be the perfect solution? Should the Batik Paint Objects simply carry the flag of the original gradientUnits, so we dont need a heuristic for this decision?
2. Why is this not a problem for the png painter? (This is more of a question for myself, because the answer is in Discrepancy between PDF & PNG when translating an SVG that contains a linear gradient #19 and i would need to understand the different standards. I see that Batik already does gradientUnit specific tranformations in its code, but in contracts to png image graphics, for PDF more things need to be translated.)

[rototor]

Hmm, Batik is in "security-fixes-only" maintenance mode. Good luck to get that in... even bugfixes are not merged, so likely no chance for new features. But you might try anyway.

Maybe I should try at some point to see if https://github.com/css4j/echosvg would work with this library. This fork at least tries to maintain the whole thing.

[rschmunk]

Thumbs up for @css4j/echosvg . I was adding or updating SVG output to an app of mine a year ago. After a bit of wrangling with the maintainer, I got a nice clean archive I could use that produced output as good or better than Batik, but the jar was same size or smaller and I could rely on an active developer managing the project.