[Libreoffice-ux-advise] [Bug 34436] TABLES text in cells behaves wrong when rotated (Shift Enter needed for line - see comment#3)

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Feb 25 14:24:18 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=34436

--- Comment #39 from Frank <foberle at enteract.com> ---
Fascinating...  Yet another "Special Case" in Writer.

Why not carry this to its logical conclusion? When one rotates a page (rather
than just a cell) from portrait to landscape mode, let's add a different set of
behaviours for text handling. For example, as Keiko describes: "Just enter
123456, rotate, and add a break - it becomes 456 in the first paragraph
followed by 123." This would at least make Writer's behaviour consistent.

As I asked in an earlier post, why should text entry and editing within a cell
be any different at all [from a user perspective] from text entry and editing
outside a cell?

The idea of altering the documentation to describe how "456 follows 123 but
only in a cell" should prompt at least a bit of head-scratching (in logic,
adding such documentation would be akin to what is called "reductio ad
absurdum").

But, then again, if user confusion is the objective of the Writer team, has
anyone considered the other possibilities: could cell editing be coded in such
a way to have it respond differently depending on the direction of the rotation
(clock-wise or counter-clockwise), e.g. have it produce 321 654 if the rotation
is counter-clockwise? It would certainly be a shame to permit ANY opportunity
to be more user-hostile pass by.

That isn't as silly or sarcastic as it sounds by the way. Writer still handles
RTL (right-to-left, such as Arabic or Hebrew scripts) within rotated cells in a
humorous (thought not quite achieving the status of encryption) fashion -
swapping not only segments (e.g. the aforementioned 123 and 456) but individual
characters as well. A Hebrew or Arabic segment does in fact act as if it is 321
654.

Editing in cells is BROKEN and has been for at least a decade and likely
longer. It constitutes at least one BUG, and likely several. While editing or
rotating text within a cell it MIGHT BE a special case from a programming
standpoint, it should require no special knowledge or additional documentation.

Here's a quick stab at a full and complete explanation of what's expected: "".
I'll repeat: "".

If that's unclear, it means a user should have no expectation that text entry
or editing should be any different within a cell than it would be anywhere
else.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libreoffice-ux-advise mailing list