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
Text is centered
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.
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default;
Locale: ca-ES (ca_ES.UTF-8)
but not in
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 <firstname.lastname@example.org> 2015-10-04 17:14:00 (GMT)
committer Maxim Monastirsky <email@example.com> 2015-10-06 18:58:31 (GMT)
commit 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f (patch)
parent 884606e74bee007c0286a16fb8aa8fc8af9a8779 (diff)
tdf#91097 Substitute rectangle and ellipse uno commands
8e118822e67b622218480962b7f96c8f532bbdc2 is the first bad commit
Author: Norbert Thiebaud <firstname.lastname@example.org>
Date: Wed Oct 7 15:34:16 2015 -0700
:040000 040000 5e4e90a26a948b79a95d0a6889e3b546b7bc0d1e 0a68a0821e5d356e4fe2f0764a24c01c351564c7 M instdir
git bisect log
# bad: [05d11632892a322664fb52bac90b2598b7fb7544] source sha:5616d22b57a9a5e57d545e912e029162a230829b
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source sha:ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'origin/master' 'oldest'
# good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source sha:4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f
git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f
# bad: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source sha:1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2
git bisect bad 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6
# good: [ecd02a00b3cb479dcecd6a2539e2f4140cd8158f] source sha:f45ac62a20b80033a7f5ccdef4a6c116b6fece24
git bisect good ecd02a00b3cb479dcecd6a2539e2f4140cd8158f
# bad: [f079ad05806f066d91ce750402631a16eada301e] source sha:e695f173ccd3cd6c01c7191b98bb452fd387eb6d
git bisect bad f079ad05806f066d91ce750402631a16eada301e
# good: [b457317e967924fe178d778f43db995a85b5723b] source sha:a2aed0e866c8e4eb308b90967fcd81e70bcdf7fb
git bisect good b457317e967924fe178d778f43db995a85b5723b
# bad: [bd812fbe6b97b1f81a2ca506d4fa2a5c4989747b] source sha:e1208d37e4d24bc15e147ff63eb39c12f09a414b
git bisect bad bd812fbe6b97b1f81a2ca506d4fa2a5c4989747b
# bad: [d1af34e8951dd5b5acd11096bd696a8430096f45] source sha:6d7353deb891b6cb49e98fec5de2ad0f1bc86c24
git bisect bad d1af34e8951dd5b5acd11096bd696a8430096f45
# good: [6316991bbb6d5b638ffd62a7a52d4ddfe23a8cae] source sha:70409a450f62736885cf596991cdb7b42a19a88a
git bisect good 6316991bbb6d5b638ffd62a7a52d4ddfe23a8cae
# good: [d6df5572c1b2d00618c4a4d4c0536d07f52123eb] source sha:3eff65e78a3a90b07c7a01ff26736fd25996e476
git bisect good d6df5572c1b2d00618c4a4d4c0536d07f52123eb
# bad: [1afd8e1ca5ce57526a3ec359e3ae993e848589a7] source sha:6ca355d281133c1e0e54df4e4710a4e99bc38c17
git bisect bad 1afd8e1ca5ce57526a3ec359e3ae993e848589a7
# bad: [4bd2ae3fd6dcbde4eb8ae0b53e3e1ed7879d07b3] source sha:4c2339d8177d610cc23619e787c1517ce8e8afd7
git bisect bad 4bd2ae3fd6dcbde4eb8ae0b53e3e1ed7879d07b3
# bad: [8e118822e67b622218480962b7f96c8f532bbdc2] source sha:3080e4c09b7c4894d4f0f52c9beed4298f3fd23f
git bisect bad 8e118822e67b622218480962b7f96c8f532bbdc2
# good: [41f20fa9e2db9f8cd921819e6b6f2f9909680e11] source sha:884606e74bee007c0286a16fb8aa8fc8af9a8779
git bisect good 41f20fa9e2db9f8cd921819e6b6f2f9909680e11
# first bad commit: [8e118822e67b622218480962b7f96c8f532bbdc2] source sha: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.
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?
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!
Still occurs in recent master build, 126.96.36.199.alpha0+ (fdc91f7493171ae600ecb293ad380df5fa77a277) / Ubuntu 18.04.
Another false regressing commit for reference:
author Caolán McNamara <email@example.com> 2015-01-14 16:55:02 +0000
committer Caolán McNamara <firstname.lastname@example.org> 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.