Bug 148593 - "Left page border" and "right page border" options for Horizontal "to" position in Position and Size for shapes are misleading names, which should be changed
Summary: "Left page border" and "right page border" options for Horizontal "to" positi...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: sdc.blanco
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks: Image-Dialog Shapes
  Show dependency treegraph
 
Reported: 2022-04-14 12:43 UTC by sdc.blanco
Modified: 2022-09-15 10:44 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstrates actual behavior of so-called Left page border and Right page border (15.19 KB, application/vnd.oasis.opendocument.text)
2022-04-14 12:43 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2022-04-14 12:43:13 UTC
Created attachment 179556 [details]
Demonstrates actual behavior of so-called Left page border and Right page border

Attached document demonstrates Horizontal positioning for a shape 
{Left, Right, Center} to {Left page border, Right page border}.

It should be clear from the demonstration that this option controls the region between {Left, Right} page edge and page text area.

A better name for the options would be:

  "Left of page text area" 
     (and "Right of page text area") 

   or more precisely: "Region to left of page text area" 

                      "Region to right of page text area"
Comment 1 Heiko Tietze 2022-04-14 13:20:48 UTC
[Left] of [Left page border] sounds good to me and while [Right] of [Left page border] is a bit weird it works well for [Right] of [Right page border]. This *region to* is confusing. Perhaps page margin instead of border? But is this really needed?

Regina, Mike, your take?
Comment 2 Mike Kaganski 2022-04-14 13:29:05 UTC
It is called *margin*, set up in page style; and the preview in the dialog provides enough context to describe the idea.

I'd just replaced "border" (definitely wrong) with "margin" everywhere, and be done.
Comment 3 sdc.blanco 2022-04-14 14:39:59 UTC
(In reply to Mike Kaganski from comment #2)
> I'd just replaced "border" (definitely wrong) with "margin" everywhere, and
> be done.
It would be wrong.  Your statement is true only if there is no padding in the page style.  See page 2 of attachment for illustration of what happens when there is padding.

These controls seem to function (for the left and right sides of page text area) as "page text area top" and "page text area bottom" function for the regions above and below the page text area.
Comment 4 Mike Kaganski 2022-04-14 15:09:13 UTC
(In reply to sdc.blanco from comment #3)
> It would be wrong.  Your statement is true only if there is no padding in
> the page style.  See page 2 of attachment for illustration of what happens
> when there is padding.

Oh! You are absolutely correct. Thanks - I missed the second page completely!

No suggestion from me - the bulky suggestion in comment 0 looks technically correct.
Comment 5 Regina Henschel 2022-04-14 17:58:00 UTC
(In reply to Heiko Tietze from comment #1)
> [Left] of [Left page border] sounds good to me and while [Right] of [Left
> page border] is a bit weird it works well for [Right] of [Right page
> border]. This *region to* is confusing. Perhaps page margin instead of
> border? But is this really needed?
> 
> Regina, Mike, your take?

The wording should neither contain "Margin" nor "Border". The region in question is "page margin area" plus "page border area" plus "page padding area". Thereby "margin", "border" and "padding" are used as defined in CSS, see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Model/Introduction_to_the_CSS_box_model or https://drafts.csswg.org/css-box/#box-model.

It could be named
page region left of page content area

But that is too long for the drop-down list.

You need "page" in the item, because you have regions related to paragraphs in the same list.

Perhaps a total different concept is needed, for example a large preview, which has place enough to show the regions in question and has for each region an identifier that can be used in the list.

The paragraph related items have the same wording problem.
Comment 6 Eyal Rozenberg 2022-04-20 09:04:17 UTC
So, I'll chime in, having noticed this on the design meeting agenda.

Generally, the Position&Size tab is a mess!

* Anchoring seems to conflict with position
* Position seems more like alignment
* The interaction of position protection semantics with alignment and anchoring are anybody's guess.
* What does protecting the size even mean, if there's no other control which affects the size?

Specifically to this issue, the suggested renaming doesn't help, because the combined text + textbox values don't result in a reasonable sentence or phrase.

"Position: Horizontal: Left by 0.00 inch to Left page border"

Huh?

Now, sdc.blanco says: 

> It should be clear from the demonstration that this option [{Left, Right} to page border] controls the region between {Left, Right} page edge and page text area.

Why? 1. That's not clear from the demonstration and 2. I don't even think that's true. How does it have anything to dox with the text area?


------

What could be done IMHO to improve things some, is a deeper change.

First, we need willing to alter or remove some of the labels and textboxes when drop-down box selections change. I know Heiko won't like this, and I can sympathize, but better to have UI that is a little less static-and-stable, then for it to be confusing and sound like gibberish. In Hebrew there's a proverb: "If you have caught multiple things - you have caught nothing" (תפסת מרובה - לא תפסת).

Now, two options.

Option 1: Enable constructing the following phrases for Horizontal:

Align [F1] to [F2] with offset [F3]


F1: Left, Right, Center (and perhaps also Start and End, where these will be interpreted according to the direction of the anchored-to entity.

F2: par. area, par. text area, left page border, right page border, page start border, page end border, page inner border (when we have book margins), page outer border (when we have book margins), page text area, entire page .

F3: text box accepting both negative and positive values.

In this option, there is an implicit interpretation of which side is positive and which is negative.


Option 2: Similar to option 1, but add another field controlling the direction of offset

Align [F1] to [F2] with offset [F3] [F4]

F1: as above
F2: as above
F3: non-negative value
F4: to left, to right, towards start, towards end, inwards (when we have inner margins), outwards (when we have inner margins)

 
the same thing goes for vertical, with the following differences:

1. Top and Bottom instead of Left and Right.
2. Start is always Top and End is always Bottom, so no need for Start and End (I think).
3. I don't remember if we support vertical book margins. If we don't, then there's never any need for inwards and outwards.
Comment 7 Telesto 2022-04-20 09:28:49 UTC
(In reply to Eyal Rozenberg from comment #6)
> Generally, the Position&Size tab is a mess!

I do agree :-)


> * What does protecting the size even mean, if there's no other control which
> affects the size?

Is about resizing or dragging the the textbox in document with mouse (drag & drop and resize with drag handles)
 


> Specifically to this issue, the suggested renaming doesn't help, because the
> combined text + textbox values don't result in a reasonable sentence or
> phrase.
> 
> "Position: Horizontal: Left by 0.00 inch to Left page border"
> 
> Huh?

Well I'm struggling with the position vocabulary too :-)

> Option 1: Enable constructing the following phrases for Horizontal:
> 
> Align [F1] to [F2] with offset [F3]

This is surely an improvement on readability and even if you still struggle at first, it surely easier to figure out... :-) The current vocabulary is really confusing, IMHO.
Comment 8 sdc.blanco 2022-04-20 11:20:57 UTC
Umm….the OP is a highly specific and limited request in relation to existing UI.  It was motivated in part because the explanations for the two options named in the OP are described incorrectly in the relevant  help pages. Before revising the descriptions in the help, it would be useful to get a resolution about how those options should be named.

Comment 6 and comment 7 go far beyond the focus of the OP. Please open new tickets for issues in those comments if you want, and allow this ticket to resume its intended function.
Comment 9 Heiko Tietze 2022-04-22 09:08:11 UTC
We discussed the topic at the design meeting.

To summarize, the label must not use "Margin", "Padding" nor "Border". Long labels might be more precise for those who understand the function but not easier for laymen. And we do have a nice preview that clearly shows where the object is positioned (this could be better placed next to the controls).

CSS/PDF use Media-, Trim-, Bleed-, Crop-, and Artbox but this is not likely to be an advantage for understanding.

Rearranging the controls so the labels read as a sentence make sense. And, if possible, we should allow to always have an offset not only for "From Left" making this entry obsolete.

Something like: [Start (Left)/End (Right)/Center resp. Inside/Outside/Center] of [Paragraph area/Paragraph text area/Left paragraph region/Right paragraph region/Left page region/Right page region/Entire Page/Page Text Area] at [ 0 cm].
Comment 10 Regina Henschel 2022-04-22 13:21:14 UTC
(In reply to Heiko Tietze from comment #9)
 
> Rearranging the controls so the labels read as a sentence make sense. And,
> if possible, we should allow to always have an offset not only for "From
> Left" making this entry obsolete.

The position is specified in 20.298 style:horizontal-pos in ODF 1.3. Possible values are left, center, right, from-left, inside, outside or from-inside. So a general offset cannot be described with current ODF version.

The wording in ODF is not suitable as template. It has similar problems as LibreOffice. The ODF TC is aware of the problems but has still no solution. These includes wording problems in the related attributes 20.299 horizontal-rel, 20.397 style:vertical-pos and 20.398 style:vertical-rel.
Comment 11 Eyal Rozenberg 2022-04-22 19:09:34 UTC
(In reply to Regina Henschel from comment #10)

So, do you believe the way forward is to arrange the UI more logically, and translate back and forth from/to the ODF standard, or to change the two together?

Also, even keeping in synch with what ODF offers, rearranging boxes and rewording labels (and possibly listbox items) would still improve readability.
Comment 12 sdc.blanco 2022-04-25 22:33:46 UTC
(In reply to Heiko Tietze from comment #9)

Sorry for this off-topic comment, but...

> And we do have a nice preview that clearly shows where the object is positioned
Are you sure about that?

Have you tested the preview lately?

It is a mistake to believe that the current preview is always showing clearly where an object will be positioned.  

As Regina noted in comment 5, a ”large preview” may be a good way to reduce or eliminate uncertainty about the meanings of these options, but at present the current preview is not functioning adequately in (too) many cases.
Comment 13 sdc.blanco 2022-04-26 05:54:40 UTC
https://gerrit.libreoffice.org/c/core/+/133403
Comment 14 Commit Notification 2022-04-28 16:56:25 UTC
Seth Chaiklin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ceb1d4836d7fa04f600dea2beb146c263f8d3efa

tdf#148593  Rename two Horizontal "to" position options for Shape/Image

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.