Apache OpenOffice (AOO) Bugzilla – Issue 102548
Text adjusted to contour disappears (Draw)
Last modified: 2009-07-30 12:24:06 UTC
Draw a shape, convert it to curve or contour, add text to it, make this text to adjust the contour by right clicking on the shape and going to the "Text..." menu. Text adjusted to contour disappears. It is visible only when you edit it. Please watch the screencast about this issue: <a href="http://www.youtube.com/watch?v=sdzDC7oSVDs">YouTube - (?) Text adjusted to contour</a> . This is found in DEV300m49 and OOO310m11 on Linux and in OOO310m11 on Windows XP.
Error as described and shown in video :) The same file shows the text correct in OOo3.0.1 on WinXP.
This issue is not in OO.o 3.0.1 on Linux and Windows.
Do not set the target milestone. That will be done by the developer. Please read http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority to see, that it is not a P2 issue.
Maybe it is not so obvious that it is a P2 issue, because in the example with the ellipse this functionality is not needed at all. But what about this text-shape? (see attachment below) Or any other custom text-shape? This issue is enough important, IMHO, especially because it is not a new feature, but a break.
Created attachment 62828 [details] text-shape
Exact
AW: Checked the polygons who are involved in the primitives; one starting from the ellipse, the other from the polygon object. These are equal, so there must be someting else. Looking for DrawOutliner setup differences staring at SdrTextObj::impDecomposeContourTextPrimitive...
AW: Found. Problem is that all the decomposition stuff is layouted for unified geometry data and an object transformation holding the whole transformation stack. For historical reasons (the old polygon had only integer, so it colud not be in unified coordinates, this would have resetted all data to 0 and 1) it's different for path objects. Normally the combination of object transformation and unified geometry describes everything, whereby the scale is in the transformation. For the path object, the scale is applied to the polygon (geometric data) and is extracted (set to 1.0, 1.0) in the transformation. In the assumed combination, all leads to equal results (e.g. for getting the real poygon, it gets transformed with the transformation; it makes no difference where the scale is loacted). But (of course :-)) there is an exception: The polygon setup for contour text decomposition in combination with the (old) outliner stuff needs the scale separated (since it still operates on old integers). Guess where the scale is taken from...? From the object transformation where it's (1.0, 1.0) for the polygon case... There are two solutions: (a) Change SdrPathPrimitive2D constructor calls (only one) to get the correct data representations (b) check if the scale is 1.0/the polygon has some size in impDecomposeContourTextPrimitive and get the scale from the polygon While (a) is technically cleaner, (b) is less dangerous. Evaluating...
AW: Modifying SdrPathPrimitive2D. There, the basegfx::B2DPolyPolygon member maUnitPolyPolygon already has the inteded name, so it seems to have the scaling in the object transformation always was intended. That change will influence the decompositions of drawinglayer::primitive2d::SdrPathPrimitive2D, so i need to test some cases. Only visualisations can be influenced, though (due to primitive usage). Taking a look...
AW: Checked line handling thoroughly; especially lines with two points and bezier polygons with just one point. All works well, also the task itself is solved. Since for the user this looks like a data loss i will take this on 3.1.1. Adding to CWS aw074, too...
AW: Commited changes, done.
AW: Ckecked with wntmsci12.pro build, works as expected.
AW->WG: Please review as described.
Verified in CWS.
Tested in m17. Closed.