Reproduction instructions: 1. Create a new presentation 2. Insert a textbox of size roughly 5cm x 5cm (the exact size doesn't matter all that much) 3. Type some text into the textbox, e.g. "Hello world. This is some text." 4. (Unnecessary, just for better visualization) set the textbox to have a border (a contiguous, rather than empty, 'Line Style') 5. Right-click the edge of the textbox 6. Check "Autofit text" Expected results: The textbox' height and/or width change, so that it doesn't have empty space that could fit additional lines of text. Actual results: Nothing happens. (But if you type in more and more text, which would otherwise exceed textbox dimensions, the font size is decreased so that the whole text fits the box). So, what's the actual problem here: There are several, actually: 1. "Autofit text" is ambiguous: It can mean "Have the text fit the object, automatically", but it can also mean "Have the object fit its text, automatically". 2. An action on the text area appears in the object's context menu (not the context menu you get when you're editing the text, when the text area is active/indicated visibly). 3. The user may be expecting to be able to resize the object to fit its text from the object's context menu, where the user sees additional items affecting object size, like the "Position and Size..." item. At the very least and immediately, the menu item should be reworded (in English and other relevant locales). It could be: "Auto-fitting text" or "Make text auto-fit" for example. That would address (1.) But I also believe (3.) should be addressed, by somehow also letting the user say they want the object size to auto-fit the text from the context menu without entering a separate dialog.
Seen with: Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US but this is from much earlier.
(In reply to Eyal Rozenberg from comment #0) ... > 5. Right-click the edge of the textbox > 6. Check "Autofit text" > > Expected results: > > The textbox' height and/or width change, so that it doesn't have empty space > that could fit additional lines of text. The expectation is wrong. The tool "Autofit text" belongs to the ODF attribute "style:shrink-to-fit"[1]. It changes the font size, not the shape size. The property you are looking for is the setting "Fit width to text" and "Fit height to text". These are in the text attributes properties of the shape. [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420164_253892949
(In reply to Regina Henschel from comment #2) > The expectation is wrong. Indeed, the expectation is "wrong" in the sense that LO did not intend to fulfill this expectation. But evoking "wrong" expectations of many users _is itself a bug_. > attribute "style:shrink-to-fit"[1]. It changes the font size, not the shape > size. > > The property you are looking for is the setting "Fit width to text" and "Fit > height to text". These are in the text attributes properties of the shape. Yes, I know that. The point is, the user does not know that, and due to the reasons I mentioned earlier, develops the "wrong expectation". I'll rephrase that title to clarify this.
This is a RTM issue -- users should, but contributors for sure... https://books.libreoffice.org/en/IG75/IG7506-FormattingGraphicObjects.html#toc65 https://books.libreoffice.org/en/DG75/DG7509-AddingAndFormattingText.html#toc24
(In reply to V Stuart Foote from comment #4) Read the manual is a second best solution, IMHO. Why label something in UI as 'Auto-fit' if it's actually modifying an attributed called "shrink-to-fit". Or to take a different perspective: why did the ODF committee pick attribute name: 'shrink-to-fit' instead of 'Autofit text' (still resulting in shrink-to-fit). Auto-fit text is unnecessary vague. Alternative (descriptive label) * Fit text to textbox * Fit textbox to text The 'auto' in the label doesn't add much value. This already communicated by the toggling aspect: the 'V' after toggling it on. -------------------------- FWIW: some kind of "fit textbox to text" feature would be nice (equivalent to shrink-to-fit). There is a feature position and size tab -> has setting for Fit width to text/Fit height to text however this horrible confusing labeling Fit Height to Text is enabled by default: effect: grow the textbox, if the containing text is larger compared to defined height. The textbox does shrink when removing text. However until the original size of the textbox is reached Fit Width Text increases the width of the textbox
Some related questions: Question A There is a "fit height to text" and "fit width to text" in the "position and size" dialog on the "position and size" tab in Impress, not Writer. Why different? Question B There is also the "text attribute dialog" for text boxes. On the "Text" tab there is a section "Drawing Object Text" "Fit Width to text" & "Fit Height to text" for Writer & Impress I'm kind of confused what the difference is. And in case of Impress, how both types of settings interact
(In reply to V Stuart Foote from comment #4) > This is a RTM issue There is no such thing as a RTM issue regarding the UI. If you need to read the manual to understand anything, then the UI is buggy in terms of usability. > users should Actually, they shouldn't. The manual is a convenience feature for people who like to learn how to use an application that way. There are exceptions, I suppose, like super-complex / heavily-configurable features - where perhaps you really must have the user read the manual. But that's not the general case and not the case here. Also, the users don't read the manual, and won't. (And I make it a point not to bias my QA work by whatever the manual says.)
(In reply to Eyal Rozenberg from comment #7) > (In reply to V Stuart Foote from comment #4) > > This is a RTM issue > > There is no such thing as a RTM issue regarding the UI. If you need to read > the manual to understand anything, then the UI is buggy in terms of > usability. > > > users should > > Actually, they shouldn't. The manual is a convenience feature for people who > like to learn how to use an application that way. > > There are exceptions, I suppose, like super-complex / heavily-configurable > features - where perhaps you really must have the user read the manual. But > that's not the general case and not the case here. > > Also, the users don't read the manual, and won't. (And I make it a point not > to bias my QA work by whatever the manual says.) Sorry but that is absolute nonsense! Functional software is by its nature *NOT* self documenting. Users must RTM! Which is why the project makes considerable effort to document use, and provides localized Help builds online, and installed. We can only do so much with UI hints and reasonable UX considerations--but we absolutely must insist that users RTM and continue to author comprehensive user manuals and localized Help.
(In reply to V Stuart Foote from comment #8) > Sorry but that is absolute nonsense! ... Users must RTM!... > we absolutely must insist that users RTM and continue to author > comprehensive user manuals Come on, Stuart... the overwhelming majority of users of office suites have not read the manual for decades, and will not read the manual in the future. And nobody "insists" that they do this. > Functional software is by its nature *NOT* self documenting. First let's make the distinction between "requires documentation to use" and "self-documenting"; but ignoring that, it's certainly true that: * A lot of functional software requires reading documentation in order to use. * Non-requiring-documentation-to-use is indeed not part of the _nature_ of functional software. still, a decent office suite like LO doesn't require documentation to use. Not because this non-requirement is in the "nature" of an office suite, but because if it required reading a manual it would be a poor office suite. Which LO isn't. > Which is why the project makes considerable effort to document use, and > provides localized Help builds online, and installed. Help and manuals are useful for many users, for sure. But the UI must not rely on them being read. They are at most a "secondary line of defense" to partially borrow from Telesto's phrasing. > We can only do so much with UI hints and reasonable UX considerations-- We can do enough :-) and that is the case here. Yes, there is some functionality is super-complicated and can't be fully related to the user intuitively. But that's really very little - especially in Impress/Draw.
How about "Shrink font size"? It is still not self-explanatory, though ("Adjust font size to text box" would be but means to also enlarge the font).
(In reply to Heiko Tietze from comment #10) > How about "Shrink font size"? It is still not self-explanatory, though > ("Adjust font size to text box" would be but means to also enlarge the font). What that means, is that if you check the box, the font size will shrink - regardless of whether the text is too long or not. So, that is even worse :-P It could be "Shrink font to fit" or "Shrink font to fit box" is somewhat better, but I still don't like it. But then, I don't really like the other options I mentioned. What I would like the most is to have a submenu with autofit-related options, and that would also allow more text - in the submenu title and in the item name.
(In reply to Eyal Rozenberg from comment #11) > What that means, is that if you check the box, the font size will shrink - > regardless of whether the text is too long or not. So, that is even worse :-P And you don't even dare to try such a function? I was pondering over a more verbose string but better have it short and not 100% accurate than overly long raising more questions.
(In reply to Heiko Tietze from comment #12) > (In reply to Eyal Rozenberg from comment #11) > > What that means, is that if you check the box, the font size will shrink - > > regardless of whether the text is too long or not. So, that is even worse :-P > > And you don't even dare to try such a function? Exactly... > I was pondering over a more > verbose string but better have it short and not 100% accurate than overly > long raising more questions. I could live with that kind of trade-off - but only as long as what it wants to say is obvious enough. How about "Shrink text to fit" or "Text shrink-to-fit"?
(In reply to Eyal Rozenberg from comment #13) > "Shrink text to fit" Let's take this. Code pointer: .uno:TextAutoFitToSize in officecfg/registry/data/org/openoffice/Office/UI/DrawImpressCommands.xcu
(In reply to Heiko Tietze from comment #14) So, shall we constrain this bug to the label change, and leave points (2.) and (3.) from the opening comment for separate bugs? In that case, I'll rephrase the title.
(In reply to Eyal Rozenberg from comment #15) > So, shall we constrain this bug to the label change Yes, makes sense
Ioan-Teodor Teugea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c476335c4d3e1b9c90485e4e13fa3e2e85535143 tdf#156918: make autofit text less confusing It will be available in 24.2.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.
I could not find any occurrences in Help, so I guess this is done.
Should a label text bug be considered fixed with just the en-US locale being corrected? What about invalidating the other translations, and perhaps even updating some? At least for a few popular languages (Chinese, Spanish, German, Farsi, French, Italian or some of them)?
(In reply to Eyal Rozenberg from comment #19) > Should a label text bug be considered fixed with just the en-US locale being > corrected? What about invalidating the other translations, and perhaps even > updating some? At least for a few popular languages (Chinese, Spanish, > German, Farsi, French, Italian or some of them)? Yes, it should be considered fixed. Translations will be invalidated anyway.
Setting to NEEDINFO to remove from beginner easy hacks list.
Command was renamed, as suggested in comment 13. Now just the help need to be aligned.
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/a0b6f31df93d28945631938fd5dfb5c5687af1f1 tdf#156918 Help page for Shrink text on overflow.