Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Import / Insert SVG: Y-scale of gradientTransform-matrix is not applied to radius in y-direction, but only to center point|
|Product:||Draw||Reporter:||Regina Henschel <rb.henschel>|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||P3||CC:||Armin.Le.Grand, issues, rainerbielefeld_ooo_qa|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description Regina Henschel 2013-02-20 00:52:45 UTC
Created attachment 80304 [details] transformed radial gradient for transformed shape The attached files contain the same radial gradient. Its gradientTransform attribute has a matrix with different scale in X- and Y-direction. This gradient is referenced from the fill of a rectangular path. The radial gradient has only one radius attribute. But when it is transformed, it is no longer a circle, but becomes an ellipse and needs a radius for X-direction and a radius for Y-direction. In Draw the radius in Y-direction is the same as the radius in X-direction. Open the attached svg-pictures in an actual browser and insert them into Draw-document. Compare it to see the error.
Comment 1 Regina Henschel 2013-02-20 00:54:23 UTC
Created attachment 80305 [details] transformed radial gradient for shape with only shift
Comment 2 Rainer Bielefeld 2013-05-13 05:15:25 UTC
Reproducible with server installation of "AOO 3.4.1 – German UI / German locale [AOO341m1(Build:9593) - Rev.1372282]" on WIN7 Home Premium (64bit)", own separate user profile: In Seamonkey Browswer or inserted into LibO DRAW both sample.svg are shown with light blue rectangle surrounding gradients ellipses. In AOO the gradient areas exceed the light blue rectangle at top and bottom. It does not matter whether samples are opened with AOO Craw or inserted as 'Picture from File' Was ok with 3.4.1, so REGRESSION
Comment 3 Armin Le Grand 2013-05-15 08:46:18 UTC
ALG: Problem is that indeed (as Regina shows) the transformation is applied to the radius in case of a SvgLinearGradientPrimitive2D to create the basic geometries. This cannot reflect a uneven scaling in the transformation at all. As alternative two radii would be usable, but the transformation is not restricted and could thus contain all kinds of transformations. Another alternative would be to use vectors as X and Y-Axis what would work, but is in tiT#s functionality to transporting an embedded coordinate system identical to using the transfomation directly. Thus, best solution is to transport that transformation in the primitive and to apply it in it's decomposition. Anyways that transformation was applied in the wrong place, as the SVG spec says ("This additional transformation matrix is post-multiplied to (i.e., inserted to the right of) any previously defined transformations"). Added to th eprimitive, aplying where defined, works. Also corrected a bug that 'display' statements may be part of a combined 'style' statement and was not applied correctly in this case. Corrected some other minor stuff, too. Checked with the testfiles, also created one for a linear gradient with transformation, works well. Preparing checkin...
Comment 4 SVN Robot 2013-05-15 08:51:15 UTC
"alg" committed SVN revision 1482726 into trunk: i121801 Corrected handling of gradient transformations
Comment 5 Armin Le Grand 2013-05-15 09:50:42 UTC
ALG: Checked with #120616# and found another problem - had to adapt applying the transformation for objectBoundingBox case. Also cleanup.
Comment 6 Armin Le Grand 2013-05-15 09:51:54 UTC
ALG: Okay, all examples look good now.
Comment 7 SVN Robot 2013-05-15 09:59:30 UTC
"alg" committed SVN revision 1482740 into trunk: i121801 Corrected objectBoundingBox case for GradientTransform
Comment 8 Armin Le Grand 2013-05-15 17:04:40 UTC
ALG: Probably done with #122318#
Comment 9 Armin Le Grand 2013-05-15 17:05:12 UTC
ALG: OOps, wrong task. Please ignore comment before this one
Comment 10 Regina Henschel 2014-08-01 13:51:10 UTC
Verified in AOO411m4(Build:9774) - Rev. 1614049 (=RC1)