In recent versions of the Writer and Calc, the text in a shape has changed from centered to middle-left. The UI does not match this new setting. It's also inconsistent, as the text is centered in Draw and Impress. Steps to Reproduce: In a recent build of LibreOffice 5.4 1. Insert Shape->Basic-> Rectangle or Ellipse 2. Type some text Expected Result: Text is centered Actual Results: Text is middle-left aligned. If you go to Format -> Text Box -> Text Attribute -> Text Anchor The UI shows centered. This is wrong. If you change it, Hit OK, Go back and change it to centered the text will move to the center position where it belongs. A minimal fix to this bug is to make the UI match the positioning. A better fix would be change the default text position to centered like it is in earlier versions of LibreOffice such as 4.4.
Reproduced in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) but not in Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8)
This seems to have begun at the below commit. Adding Cc: to Yousuf Philips; Could you possibly take a look at this one? Thanks author Yousuf Philips <philipz85@hotmail.com> 2015-10-04 17:14:00 (GMT) committer Maxim Monastirsky <momonasmon@gmail.com> 2015-10-06 18:58:31 (GMT) commit 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f (patch) tree 002245f9d0ac664e2178876704d37eb86b81d9b6 parent 884606e74bee007c0286a16fb8aa8fc8af9a8779 (diff) tdf#91097 Substitute rectangle and ellipse uno commands 8e118822e67b622218480962b7f96c8f532bbdc2 is the first bad commit commit 8e118822e67b622218480962b7f96c8f532bbdc2 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Oct 7 15:34:16 2015 -0700 source 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f source 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f :040000 040000 5e4e90a26a948b79a95d0a6889e3b546b7bc0d1e 0a68a0821e5d356e4fe2f0764a24c01c351564c7 M instdir git bisect log # bad: [05d11632892a322664fb52bac90b2598b7fb7544] source 5616d22b57a9a5e57d545e912e029162a230829b # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start 'origin/master' 'oldest' # good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source 4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f # bad: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source 1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2 git bisect bad 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6 # good: [ecd02a00b3cb479dcecd6a2539e2f4140cd8158f] source f45ac62a20b80033a7f5ccdef4a6c116b6fece24 git bisect good ecd02a00b3cb479dcecd6a2539e2f4140cd8158f # bad: [f079ad05806f066d91ce750402631a16eada301e] source e695f173ccd3cd6c01c7191b98bb452fd387eb6d git bisect bad f079ad05806f066d91ce750402631a16eada301e # good: [b457317e967924fe178d778f43db995a85b5723b] source a2aed0e866c8e4eb308b90967fcd81e70bcdf7fb git bisect good b457317e967924fe178d778f43db995a85b5723b # bad: [bd812fbe6b97b1f81a2ca506d4fa2a5c4989747b] source e1208d37e4d24bc15e147ff63eb39c12f09a414b git bisect bad bd812fbe6b97b1f81a2ca506d4fa2a5c4989747b # bad: [d1af34e8951dd5b5acd11096bd696a8430096f45] source 6d7353deb891b6cb49e98fec5de2ad0f1bc86c24 git bisect bad d1af34e8951dd5b5acd11096bd696a8430096f45 # good: [6316991bbb6d5b638ffd62a7a52d4ddfe23a8cae] source 70409a450f62736885cf596991cdb7b42a19a88a git bisect good 6316991bbb6d5b638ffd62a7a52d4ddfe23a8cae # good: [d6df5572c1b2d00618c4a4d4c0536d07f52123eb] source 3eff65e78a3a90b07c7a01ff26736fd25996e476 git bisect good d6df5572c1b2d00618c4a4d4c0536d07f52123eb # bad: [1afd8e1ca5ce57526a3ec359e3ae993e848589a7] source 6ca355d281133c1e0e54df4e4710a4e99bc38c17 git bisect bad 1afd8e1ca5ce57526a3ec359e3ae993e848589a7 # bad: [4bd2ae3fd6dcbde4eb8ae0b53e3e1ed7879d07b3] source 4c2339d8177d610cc23619e787c1517ce8e8afd7 git bisect bad 4bd2ae3fd6dcbde4eb8ae0b53e3e1ed7879d07b3 # bad: [8e118822e67b622218480962b7f96c8f532bbdc2] source 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f git bisect bad 8e118822e67b622218480962b7f96c8f532bbdc2 # good: [41f20fa9e2db9f8cd921819e6b6f2f9909680e11] source 884606e74bee007c0286a16fb8aa8fc8af9a8779 git bisect good 41f20fa9e2db9f8cd921819e6b6f2f9909680e11 # first bad commit: [8e118822e67b622218480962b7f96c8f532bbdc2] source 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f
This is not a regression, and actually inherited from OOo. In pre-5.0 the affected shapes could be accessed in the "Basic Shaped" toolbar dropdown. We switched the toolbar/menubar by default to these implementations because they're generally more advanced (e.g. properly support text wrap, 3D extrusion). And the old Rectangle/Ellipse can still be found in the customization dialog. (In reply to Luke from comment #0) > If you go to > Format -> Text Box -> Text Attribute -> Text Anchor > > The UI shows centered. This is wrong. What makes it not respect the centered anchor is the "Full width" checkbox. It's enough to uncheck it. Actually this checkbox is also checked by default in Impress, but it doesn't seem to have any effect there (unless I'm missing something), which is probably a bug by itself.
(In reply to Maxim Monastirsky from comment #3) > What makes it not respect the centered anchor is the "Full width" checkbox. > It's enough to uncheck it. Actually this checkbox is also checked by default > in Impress, but it doesn't seem to have any effect there (unless I'm missing > something), which is probably a bug by itself. Maxim, Thanks for investigating this. I noticed that in Impress the text format of shapes is centered, while in Writer it's left-aligned. Could we resolve this inconsistency by making these new advanced shapes use the same defaults(Center Align) as older versions of libreoffice and Impress/Calc?
Tamás, I see you're working on related shape text alignment. Could we set these new advanced shapes to use the same defaults(Center Align) as older versions of libreoffice and current Impress/Calc? For some reason, these new ones default to left-aligned.
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still occurs in recent master build, 6.3.0.0.alpha0+ (fdc91f7493171ae600ecb293ad380df5fa77a277) / Ubuntu 18.04. Another false regressing commit for reference: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c0948f29ebd61a232406c30c306d7d8b23a596a6 author Caolán McNamara <caolanm@redhat.com> 2015-01-14 16:55:02 +0000 committer Caolán McNamara <caolanm@redhat.com> 2015-01-14 20:30:08 +0000 Use the same advanced Ellipse and Rectangle shapes in writer as draw
If for a custom shape the option "Full width" is checked and option "Word wrap text in shape" is not checked and text lines are wider than the text area width, then I expect this behavior: A paragraph with alignment "left" starts at the left edge of the text area and overflows to the right. A paragraph with alignment "center" is so aligned, that its center is positioned at the center of the text area. This paragraph overflows equally to both sides of the text area. A paragraph with alignment "right" ends at the right edge of the text area and overflows to the left. So the anchor of the paragraph is the same compared to the situation, if the paragraph is smaller than the width of the text area. The only difference would be, that it overflows at the not anchored end. Such behavior would correspond to text position in PowerPoint for the case of attribute AnchorCtr="0" on OOXLM. Currently the paragraphs are aligned to the edges of the longest paragraph and the entire text block is then positioned into the text area of the shape. But that is the behavior, when "Full width" is not checked. Currently positioning depends on the type of the shape in Impress. For type "non-primitive" and type "ooxml-foo" (those imported from PowerPoint), the text block is aligned to the left edge of the text area. For own shapes (derived from MS Office binary) the alignment depends on the first paragraph in the text block. I consider neither of the current behaviors as correct and neither of the previous positioning.
Dear Luke, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Inconsistent format still between shapes, ex Rectangle and Square. Version: 7.3.0.0.alpha1+ (x86) / LibreOffice Community Build ID: 4be0ae19065b1b50870bc0b2a28189ad39c96a8a
Dear Luke, 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