Bug 106503 - Text Position in Writer And Calc Shapes is Inconsistent / Should Use the old defaults(Center Align)
Summary: Text Position in Writer And Calc Shapes is Inconsistent / Should Use the old ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shapes
  Show dependency treegraph
 
Reported: 2017-03-12 04:09 UTC by Luke
Modified: 2019-10-13 14:50 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2017-03-12 04:09:40 UTC
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.
Comment 1 Xisco Faulí 2017-03-12 16:03:14 UTC
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)
Comment 2 raal 2017-03-13 18:52:59 UTC
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 sha:3080e4c09b7c4894d4f0f52c9beed4298f3fd23f

    source sha:3080e4c09b7c4894d4f0f52c9beed4298f3fd23f

: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
Comment 3 Maxim Monastirsky 2017-03-14 08:13:29 UTC
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.
Comment 4 Luke 2017-03-14 20:45:32 UTC
(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?
Comment 5 Luke 2017-03-19 19:02:17 UTC
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.
Comment 6 QA Administrators 2018-03-20 03:35:24 UTC Comment hidden (obsolete)
Comment 7 Aron Budea 2019-01-23 15:58:26 UTC
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
Comment 8 Regina Henschel 2019-10-13 14:50:27 UTC
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.