Description: Checked with rectabgle and lines: If text is formatted to be completely outside (left or right side) of the object, it is not displayed. Can be edit with F2 but is invisible afterwards. Checked on 2 computers, each with Windows 10 Pro. Checked with LibreOffice 7.2.2, 7.1.7.2 and 7.1.3.2: all failed. Checked with LibreOffice 6.4.7.2 and 7.0.6.2: both are fine. Checked with freshly installed LibreOffice. Steps to Reproduce: 1. Open a new draw file. 2. Draw a rectangle. 3. Enter F2 and enter a text in the rectangle. Up to now, everything is fine. 4. Now, open dialog to change text attributes (I will attach an example file). Align text to the left edge and set distance to the edge greater or equal than the rectangle width. 5. Leave edit mode. Text is invisible. 6. Enter F2: Text is available in edit mode. Actual Results: Text is invisible when formatted completely outside the rectangle. Expected Results: Visible text. Reproducible: Always User Profile Reset: No Additional Info: Problem could be reproduced on different Windows 10 Pro computers and with new LibreOffice installation.
Created attachment 176123 [details] Example to show the bug with rectangle and line.
I can confirm the problem with Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: b6c3adf356ca5f7b6f3d80e6062b58c92e6e2a11 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: de-DE (en_US); UI: en-US Calc: threaded AOO shows the text if directly at the shape edge. It does not move the text further left, regardless of the entered value.
Thank you for pointing out this issue: I actually experience it when I offset text from a line, but I didn't try to find out where it came from.
For custom-shapes there is this situation: The distances in the "Text attributes" dialog define a padding-area in the sense of https://www.w3.org/TR/CSS2/box.html#box-padding-area. If the padding is so large, that there is zero width or height of the content area, then it might be valid to say, that then no content can be there. But I have not found a rule, what to do. To reduce confusion of users a solution could be, to restrict the distance values in the dialog so, that this situation does not occur. If you define your own custom-shape, you can workaround the problem by using a suitable 'draw:text-areas' attribute. For other shapes than custom-shapes, e.g. lines, no such explicit text area exists. It might be possible to use a text area which reaches in the direction opposite to the anchor to the document boundary. Astonishingly there is no such problem, when placing text above or below the line.