Description: I am pretty sure that in the past it was possible to set the text anchor and the paragraph alignment in a completely independent way. For instance it was possible to have a text box anchored at the top left corner with a paragraph taking right alignment. Now this seems to be impossible. When you set the box anchoring to some left corner, the text automatically takes a left alignment and when you make the text box right anchored its text is automatically right aligned, completely ignoring the paragraph alignment setting. This has two major consequences: - It breaks the layout of legacy documents - It makes it impossible to have a text box with one paragraph aligned left and another one aligned right. Steps to Reproduce: 1. Create an empty impress document 2. Place a text box in a slide 3. Enter two paragraphs in the text box 4. Give the first paragraph a left alignment and the second paragraph a right alignment using the paragraph properties (so far so good) 5. Now check the text box attributes, see that the default anchoring is at the top center 6. Change the anchoring to the top left corner. See that the two paragraphs become left aligned 7. Change the anchoring to the top right corner. See that the two paragraphs become right aligned 8. Try to get again an alignment with one paragraph left aligned and the other one right aligned Actual Results: It is impossible to perform point 8 Expected Results: Textbox anchoring and paragraph alignment should be independent properties as they were in the past. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
According to https://ask.libreoffice.org/t/lo-draw-why-do-i-have-to-use-text-anchors-instead-of-paragraph/27290 this has been going on since at least LibO 5.3
Confirm Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL but also with 3.5.7.2 I would expect text anchor being in depended of alignment too, but well not 100% sure
Main issues with the current setup are two: 1. Behavior changes after you first touch the text box anchor 2. After you touch the text box anchor it becomes impossible to have a text box with a paragraph left aligned and another one right aligned
Obviously, the text anchor (TA) overwrites the paragraph alignment (PA). And doesn't it make sense given that you want to place the text at the lower right border, for example, to not use left alignment? The issue is not restricted to Impress. The text box works the same in Writer. You can check "Full width" to retain control over the paragraph but I admit this is not a clear workflow. First of all, we should disable PA commands if TA is set. Second, "Full Width" could be renamed to "Use paragraph attributes" and implemented as radio button together with "Use box anchor", or the like. And we also need a better documentation. Neither online [1] nor offline makes it clear what Text Anchor is. Have I missed something, Mike? [1] https://help.libreoffice.org/7.2/en-US/text/shared/01/05220000.html
Created attachment 175158 [details] Sample case
> ... the text anchor (TA) overwrites the paragraph alignment (PA). And doesn't it make sense given that you want to place the text at the lower right border, for example, to not use left alignment? I don't think it is sensible, because they are two different things with different purposes. The anchor is meant to define how the text box should grow to accommodate more text when this is needed. The paragraph alignment is there to say how the text should be aligned within the current text box boundaries. Even if it may look marginal, there may well be cases where you want the anchor on one side and the alignment from the opposite one. For instance you may want a text box predefined with a certain width where the text is left aligned, but such that — if the text becomes too wide — the box grows to the left mantaining its right boundary at a fixed position. For instance this may happen because the right boundary is on the right page boundary so rather than having the text go off the page you are willing to accept an alignment change on the left side. As already said, another issue is that the current behavior makes it impossible to have a text box with multiple paragraphs where the paragraphs take different alignments (e.g., first paragraph to the left, second one centered, third one again to the left). To be more correct, that is perfectly possible, provided you do not touch the text anchors. Once you have touched them for that text box it is not possible anymore, so if you need that then you have to erase the text box and make a new one. See the attached example document, where there are two text boxes. In each of them there are three paragraphs: the first one is left aligned, the second one is centered, the third one is right aligned. The box on the top looks fine. For the box on the bottom, the text anchor has been set and the box looks completely wrong. The paragraph that should be right aligned is left aligned and the paragraph that should be centered is weirdly spaced from the left.
The paragraph alignment is totally independent from "text anchor". As you would expect. When you set the anchor to left, you still get right-aligned paragraph right-aligned, and left-aligned ones left-aligned. What changes is the width of the "page". And that's normal, because the "full width" gets unchecked (it's only available for middle alignment), and that checkbox means "use the control's width as the width for layouting the text". When the checkbox is unchecked, the width of "page" is calculated by obtaining the width of the widest text string; and other strings are aligned on that, possibly different, page.
> The paragraph alignment is totally independent from "text anchor", as you would expect. > When you set the anchor to left, you still get right-aligned paragraph right-aligned, > and left-aligned ones left-aligned. > What changes is the width of the "page". And that's normal, because the "full width" gets > unchecked (it's only available for middle alignment), and that checkbox means "use the > control's width as the width for layouting the text". This clarifies a bit. But I still have a few items that do not look completely consistent to me: The usage of "full width" remains strange to me, possibly due to lacking documentation. - I have always assumed that the role of the anchor was to determine how the text box should automatically alter its size when there is a need to do so (namely what should remain fixed when the size is automatically altered). Is this correct? - I have always expected paragraphs to be laid out in the text box as they are in the regular page considering the size of the text box and aligning the individual paragraphs left, center, right or justified as set in the paragraph properties. I now understand that when you do not have the "full width" tick set the individual paragraphs are laidd out using their own natural width as the "page" size. Why is this needed? Is there a case where you need the full width unselected? That is something that you would not be able to do with the mere paragraph alignment controls? - Why do you say you need the full width switch off for the left and right anchoring? This makes it impossible to achieve something like what I have just described in an example. You have a text box with some predefined width and you put them close to the right border of the page. In this box you want left alignment. But you may also want right anchoring, so that if one puts in the box more text that it can fit, rather than putting the text off the page, the box can expand to the left.
(In reply to sergio.callegari from comment #8) > - I have always assumed that the role of the anchor was to determine how the > text box should automatically alter its size when there is a need to do so > (namely what should remain fixed when the size is automatically altered). Is > this correct? No. The size of *text box* (the graphical object), and the size of *text* that it contains, are two different sizes. There is an *option* to resize control automatically based on its content, but that is just an option. You need to think about the text box and its text as *two* separate (related) boxes. So when you define the anchor, you define the relation between these two boxes. The graphical object has its borders; and you define which border, or which corner, of the graphical object will be considered the starting point (anchor) when starting to lay out the text. The text will start from there, but will not consider the other elements of the graphical object. > - I have always expected paragraphs to be laid out in the text box as they > are in the regular page considering the size of the text box and aligning > the individual paragraphs left, center, right or justified as set in the > paragraph properties. I now understand that when you do not have the "full > width" tick set the individual paragraphs are laidd out using their own > natural width as the "page" size. Why is this needed? Is there a case where > you need the full width unselected? That is something that you would not be > able to do with the mere paragraph alignment controls? This is the common property of the graphical objects, of which the text box is just one example. There are other types - e.g., you may type text inside rectangles or ellipses, or inside raster images. You might not want tour text to consider the owning object's dimensions - you may only need the text to *relate* to the object, but not use its bounds. > - Why do you say you need the full width switch off for the left and right > anchoring? Someone ;) had written in comment 6: > The anchor is meant to define how the text box should grow to accommodate more > text when this is needed. This was not *completely* correct, but if you rectify it like this: "The anchor is meant to define how the text's (not necessarily its owner object) bounds should grow to accommodate more text when this is needed" this helps to understand why. If you anchor the text so that it would *grow* from left, it *necessarily* means that it would grow *to the right*. But how do you intend it grow to the right, if you already set both its left and right bounds? > This makes it impossible to achieve something like what I have > just described in an example. You have a text box with some predefined width > and you put them close to the right border of the page. In this box you want > left alignment. But you may also want right anchoring, so that if one puts > in the box more text that it can fit, rather than putting the text off the > page, the box can expand to the left. No. You are just using the wrong tool for that. To make what you want: 1. You define your text box *positioned* on the page by using its "Position and Size"; there you make its horizontal position "Right" to whatever you need (e.g., paragraph area); 2. You open the text attributes dialog to define the anchor - e.g., right top corner; you also make sure that "Fit width to text" is selected; 3. You use whatever alignment of the paragraphs you need in that object.
@Mike Kaganski: Thanks this clarifies a lot! I really appreciate that you took the time to detail things so well. The way in which LibO works with objects containing text is now much more clear. There is still only one thing that I do not understand: - Why for anchors placed on the left or the right side must it be impossible to select the full width so that the full width must be automatically unselected? Even if the box and the text are two independent objects, I understand that the text should be able to get any width (otherwise it would be impossible to use the full width when the anchor is at the top or bottom center). Why cannot that width be the width of the box even in the left or right anchoring case?
(In reply to sergio.callegari from comment #10) > - Why for anchors placed on the left or the right side must it be impossible > to select the full width so that the full width must be automatically > unselected? Because anchoring at one of the sides *and* using full width would be completely the same behavior as with anchor-center+full-width.
Without reading very carefully I don't understand the function/s. Can we improve the situation? How should the documentation reflect the behavior?
(In reply to Heiko Tietze from comment #12) > Without reading very carefully I don't understand the function/s. Can we > improve the situation? How should the documentation reflect the behavior? I totally agree. My proposal would be to change the interaction first: the "whole width" checkbox should change the "anchor" control to a different shape, with only three options (top/middle/bottom), related to vertical alignment, not with 9 anchor points available otherwise. It would already be partly self-documenting.
(In reply to Mike Kaganski from comment #13) > (In reply to Heiko Tietze from comment #12) > > Without reading very carefully I don't understand the function/s. Can we > > improve the situation? How should the documentation reflect the behavior? > > I totally agree. > My proposal would be to change the interaction first: the "whole width" > checkbox should change the "anchor" control to a different shape, with only > three options (top/middle/bottom), related to vertical alignment, not with 9 > anchor points available otherwise. It would already be partly > self-documenting. And with left/center/right in case of vertical writing modes.
Because I do not know how the controls on the interface will need to map onto the ODF file structure, what I suggest here may be impractical. Still, I think that: - the idea of having an anchor for text boxes and being able to specify it to be at 9 possible positions (any corner and at any mid side) is valuable. I would not abandon it as long as it can be made straightforward to understand. - it has been clarified that the text anchor is the point of the text box that is considered fixed for the inner text (area) in which text gets laid out. - What complicates the picture IMHO is why the text area inside the text box should get a size different from that of the text box. If I understand correctly, if I make a text box, I disable the "auto fit" features, I assure that the box is sufficiently big, and I select some left anchoring, and I start typing, the area where the text is laid out will not be as large as the text box minus the margins from the text box to the text (this would be full width), but only as wide as the text that is being typed. This is why with the left anchoring the right paragraph alignment does not seem to work. It works, but in a text layout region that is just as wide as the text, so you cannot see its effects. - The behavior described above is IMHO what complicates the picture. IMHO the full width should be the default, should always be on and should by default remain on even when you select some left or right anchoring (even if in this case in the current implementation it may give you the same result as a central anchoring). This is because the average user won't know that text boxes actually involve both a graphical object and an inner text layout area and will expect a text layout area consistent with the external box. - In fact I would reverse the tick into a "minimal text layout width" one, so that you get full width when it is unselected and the expert user can select it when he/she really needs it. - In this way the average user will never get confused about the paragraph alignment buttons not working even if for some reason he selects a left/right anchoring. - In fact, I would push the thing forward. For full width text layout areas, having left, center or right anchoring should lead to the same behavior when "fit width to text" is unselected. When "fit width to text" is selected they should determine which part of the text box (the left side, the right side or the horizontal middle) should stay fixed when the text box size is automatically fitted to the text. IMHO these changes would make the text box anchoring less problematic for regular users, preventing mistakes and particularly preventing the nasty surprise of getting the impression that paragraph alignment is broken if (even by mistake) they select left or right anchoring. My two cents... I hope they make sense.
Dear Callegar, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug