Created attachment 189170 [details] Two column text in shapes The attached file contains on the first slide a dummy text. This dummy text is used for all shapes on the second and third slide. The second slide has a legacy ellipse and a polygon. The third slide has a custom shape and a text box. When you open the file you might need to click in the text to get back the two column rendering. (That is a bug of its own.) The column width is written a relative width 32767* and 32768* (Section 19.514.3 in ODF 1.3). That means, "Column widths are specified as relative widths, that is, a number followed by a "*" (U+002A, ASTERISK) character. The space available for columns is distributed according to their relative widths." So the question is, what is "space available for columns"? It should be the area for text. That is the bounding box for ellipse, polygon and text-box and the area defined by the draw:text-areas attribute for a custom-shape. When you change the anchor of the text area (Text attributes dialog) to left and then to right you can notice the left and right edge of this area. Try with an older LO version (e.g. 7.0), which does not have the multi-column feature. As the ellipse, polygon and text-box are 10cm wide, the column width should be 5cm. The text area for the custom-shape depends on the handle. In any case it is symmetric to the shape, so the second column should start in the middle of the shape. Because ellipse and polygon have no word wrap, text overflow into the next column or out of shape is correct for them. The text-box has word wrap, as soon as "fit-to-width" is off, which is the case here. But still there is overlapping text. The custom-shape has currently word wrap off. But when you enable it, the start of the columns is still wrong. There is meta bug 142729. But because not only text-boxes have this problem, the meta bug does not really fit. I have made the tests with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c9916d9be9c060d43fc063b76d70629162650fea CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL threaded
Thanks Regina. Reproduced in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: beaea2e992912b4747d790070b26371f557b1f57 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded And: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Feature was introduced in 7.2.0.0.beta1, and I see the same issue back then (with linux-64-releases bibisect repo), so calling it an implementation error. Mike, what do you think?
(In reply to Regina Henschel from comment #0) > There is meta bug 142729. But because not only text-boxes have this problem, > the meta bug does not really fit. That meta fits, just it is written from user's perspective, meaning editengine (a term not used in the UI).