Bug 156939 - "Fit height to text" is misleading, only regards growing rather than shrinking
Summary: "Fit height to text" is misleading, only regards growing rather than shrinking
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Autofit
  Show dependency treegraph
 
Reported: 2023-08-26 21:13 UTC by Eyal Rozenberg
Modified: 2024-04-18 20:36 UTC (History)
2 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 Eyal Rozenberg 2023-08-26 21:13:33 UTC
The text box Position and Size dialog, in the Position and Size tab, has the setting "Fit height to text".

When this is checked, the textbox height will only be fit to the text length if the text length _exceeds_ the original/no-text height of the textbox. If the text requires less height - the textbox will maintain its original height.

This behavior is _inconsistent_ with the "Fit width to text", which _does_ shrink the textbox horizontally if the text does not fill even one full line.

This bug is not about the functionality, but about the label. While the functionality remains as it is now - the label should be rephrased to capture it more exactly and not confuse users.

So, instead of "Fit height to text" it should something like:

* "Stretch height to fit text"
* "Extend height to fit text"
* "Increase height to fit text"
* "Increase height on text overflow"

etc.
Comment 1 Eyal Rozenberg 2023-08-26 21:14:40 UTC
Seeing this with:

Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US

but it goes way back.
Comment 2 Heiko Tietze 2023-08-28 09:24:38 UTC
I'd rather make it equivalent to the width function and also shrink the text box height.
Comment 3 Eyal Rozenberg 2023-08-28 09:32:59 UTC
(In reply to Heiko Tietze from comment #2)
> I'd rather make it equivalent to the width function and also shrink the text
> box height.

Changing the functionality is definitely a possibility, but it would be a different bug. If you think someone is going to implement that right away, then ok, otherwise - let's fix the label to say what it does, then if the functionality changes, we can change the label back.
Comment 4 Heiko Tietze 2023-08-29 08:46:31 UTC
The label is easy to understand and we should not change it unless we do the same with "Fit width to text" and have good reasons to do. I'd prefer the enhancement (and accept a minor misleading text).
Comment 5 Eyal Rozenberg 2023-08-29 21:54:52 UTC
(In reply to Heiko Tietze from comment #4)
> The label is easy to understand and we should not change it unless we do the
> same with "Fit width to text" and have good reasons to do. 

But "Fit width to text" acts differently! It _does_ shrink to fit, it doesn't just extend. The current situation is misleading, suggesting symmetry of the semantics regarding the vertical and horizontal axes.
Comment 6 Heiko Tietze 2023-09-08 06:32:38 UTC
We discussed the topic in the design meeting.

Resizing works, if not set manually but the box is still never shrunk, only stretched. Ideally this toggle would make the box both stretch and shrink as necessary.

MSO uses "[ ] Resize shape to fit text" and "[ ] Wrap text in shape"
+ "Resize shape" switches off automatically when the height changes
+ if "Wrap text" is switched off, the box is sized according the
  page width (and text still breaks)
+ if the box is resized from the page width, the "Wrap text" option
  is switched on automatically

The feature needs to be ODF compliant. We should follow MS example and enable/disable the toggles depending on the state. Renaming makes sense too.
Comment 7 Eyal Rozenberg 2023-09-08 07:16:38 UTC
(In reply to Heiko Tietze from comment #6)

A few of points:

We discussed both kinds of fitting - height and width - in the session, hence Heiko's quote referring also to width adjustment/fitting.


> Resizing works, if not set manually ... but the box is still never shrunk,
> only stretched. 

... so, not exactly. We actually noticed, if the user set an original box height, then let the stretch happen, then removed some text - the box is shrunk, up to the height originally set. There's a hidden state aspect to the current behavior.

Also wanted to clarify this part:

> The feature needs to be ODF compliant.

So, we need to have a look at the ODF spec and check:

1. Whether these toggles are explicitly defined.
2. Whether their exact semantics is defined to be what LO does now, e.g. remembering the user-set width.


> MSO ... "Resize shape" switches off automatically when the height 
> changes... We should follow MS example and enable/disable the toggles
> depending on the state.

1. We did not discuss that possibility at the design meeting.
2. I'm not at all sure this is a good idea about height. But about width - definitely not.

> Renaming makes sense too.

So, bottom line, the immediate task is to rename. We didn't bikeshed the exact string. "Stretch height to fit text" is my current favorite.