Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
In o.a.b.ext.awt.image.rendered.AffineRed.genRect, a call is made to AffineTransformOp.filter. That throws an ImagingOpException("Unable to transform src image") on the batik70.svg input.
The failure comes from the awt_parseColorModel function in src/jdk/src/share/native/sun/awt/image/awt_parseImage.c. It fails on line 514 in the test if (cmP->csType != java_awt_color_ColorSpace_TYPE_RGB || !cmP->is_sRGB). The color space is of type RGB but is_sRGB is false. So the code decides it cannot handle it.
The color model is not sRGB because, earlier in Batik, a call to o.a.b.ext.awt.image.rendered.Any2LsRGBRed.fixColorModel is made, that returns either GraphicsUtil.Linear_sRGB_Unpre or GraphicsUtil.Linear_sRGB. And despite their names, those color models use ColorSpace.CS_LINEAR_RGB which is different to ColorSpace.CS_sRGB.
That is why the boolean is_sRGB mentioned above is kept to false, and the native code refuses to handle it.
It used to be working with a 1.5 JRE. It doesn't work with OpenJDK 1.6, 1.7 and Oracle 1.8. I assume that on earlier JREs the code was less strict, possibly behaving wrongly in some cases.
The exception goes if in the definition of GraphicsUtil.Linear_sRGB et al, the CS_LINEAR_RGB color space is replaced with CS_sRGB. The image is then rendered fine.
However, that causes regressions in other test cases (one of them being regard.samplesRendering.samples.samples/batikBatik.svg), that otherwise pass. Colors become quite different to the original.
Whether using CS_LINEAR_RGB is correct or not is hard to tell. All the SVG viewers I've tried give different results. Firefox and Squiggle do tend to have similar colors, which leads me to think that they are correct. That said, the SVG Recommendation does state that SVG colors should be in the sRGB color space by default.
Leaving the code as is will make Batik fail on some inputs if run with a 1.6+ JRE. Changing the code will cause some inputs to render differently.
I guess we rather want to be conservative and leave things as is until we have a chance to further investigate the issue. Users who are facing the failure have the option to revert to an older JRE.