https://issues.apache.org/ooo/show_bug.cgi?id=124084
--- Comment #10 from Armin Le Grand <[email protected]> --- Checked the svg:d parser, all works well there. Problem is not the svg:d, but how it is used in our model. A SdrPathObj cannot be smaller/bigger than the contained polygon, so the polygon *defines* the objects size. In your correction you have 'achieved' that by adding (0,0) as a first, one-point polygon, so the SdrPathObj contains a PolyPolygon made up of two polys, the 1st with just one point. The svg:d we write (and read) is the unified PolyPolygon plus scaling (due to the fromer core need that integers are used in-between, thus unit coordinates [0.0 .. 1.0] would have been lost). This automatically means that it will always have a bounding box containing a minimum X and Y being 0.0. That is the reason that our viewBoxes always start with two zeros and have the size of the boundrect of the contained polygon. To be honest, I have no clue why ODF uses a viewBox at all; the only adaption that is made is at load time (see SdXMLPathShapeContext::StartElementline 1517) is to scale the polygon from the viewBox range to a range constructed by viewBox x,y (so the same) and the loaded object size (svg:width and svg:height). This would allow a scaling of the defined polygon (by svg:width/viewBox:width in x and svg:height/viewBox:height in y), but *no translation* of it, since minX and minY for both rabnges are defined equal, so even when using values different from zero in viewBox:x and y nothing would happen. This has been like this in all AOO versions and cannot be changed in the installed versions. The true bound rect of the imported PolyPolygon is not used currently at all. Thus, the viewBox usage in ODF has nothing to do with the intention of this statement in svg, I would have not added it initially at all, it makes things just more complicated here. So, whoever writes these files, please tell them - the polygons have to be unified, but scaled (no mirror (aka no negative scale), no shear, no rotation, no translation) - thus, the bound rect of this will have a minX/minY of 0.0 - the viewBox should have a x,y of 0.0 and a width/height identical to svg:width and svg:height - the rest of the object transform should move to (a) when not rotated, mirrored sheared: svg:x, svg:y for translation (b) else, do not use svg:x, svg:y (or set to zero) and use the draw:transform to define the full transformation, starting from the unified, scaled polygon, so scale is already in the polygon, but mirror is not. Thus, when mirrored, the transformation has to start with a scale in x and/or y of -1.0. Adding a 'M0 0' is *no* correction to be advised; as explained, this will create a PolyPolygon which looks nice, but 'artificially' expands the SdrPathObj shape. We had something similar with one of the CustomShapes, and this was leading to problems, e.g. in slideshow this single point polygons were painted and visible, do not do that please. All in all there is no error in the svg:d reader, but there are limitations in the usage of viewBox in odf that the original inventors left behind for us, without clearly specifying what intentions they had for viewBox at all. As said, the viewBox intention of svg - to scale some content somewhere and leaving white space somehere between object and content - is not even possible with the SdrPathObj in our model implementation (and makes no sense - why should a object have a size different from the bounding box of its content?). -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
