Bug 155519 - Shape's Text Box should have a "spacing to borders" frame with handles to change the values interactively (comment 12)
Summary: Shape's Text Box should have a "spacing to borders" frame with handles to cha...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shape-Textbox
  Show dependency treegraph
 
Reported: 2023-05-26 22:27 UTC by ddminnl@gmail.com
Modified: 2023-11-09 17:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Image of default text box placement (25.35 KB, image/jpeg)
2023-05-26 22:27 UTC, ddminnl@gmail.com
Details
mockup (36.54 KB, image/png)
2023-11-09 08:57 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ddminnl@gmail.com 2023-05-26 22:27:50 UTC
Created attachment 187538 [details]
Image of default text box placement

A shape's text area should be moveable and resizable with the mouse and keyboard to permit better text positioning and utilization of available space within the object without resorting to a context dialog.  The existing UI/UX method is inefficient, potentially requiring multiple iterations to place the text element satisfactorily.

In the example the "Preparation" shape's text box would look better if the text area could be moved slightly higher through keyboard or mouse adjustment.
Comment 1 Stéphane Guillou (stragu) 2023-10-31 05:52:11 UTC
Was already like this in libreoffice-4.4.0.3 (in Writer).
Text Attributes dialog allows resizing by changing the Spacing to Borders values.
Design/UX team, what do you think?
Not sure ODF allows this.
Comment 2 Heiko Tietze 2023-10-31 11:26:54 UTC
I cannot reproduce the actual issue (text box always fills the entire shape). Please share the odg file.

In general I believe the text box should fill the object (as it does), the font size should not change automatically (but not too strictly, maybe per accelerator), and the line breaking should work (as it does). We may keep some kind of "auto" attributes, meaning unless the user changed position or size it scales with the object (suspect it happens in this case).
Comment 3 Regina Henschel 2023-10-31 13:11:46 UTC
The position and size of the text-areas rectangle is often defined so, that the text does not overlap with the outline of the shape. Position and size belong to the definition of the preset geometry and should not be changed by a normal user.

ODF allows to move or resize the text-areas rectangle, but we would leave the preset geometry of the shapes then. Using the preset geometry is essential for a good round-trip with ppt and pptx formats.

The spacing values are changeable by the user, currently in the "Text attributes" dialog. The UI shows the text-areas rectangle with a thick, semi-transparent border. A frame with handles for the spacing distance could be a hairline frame. I'm not in favor of the idea, but I'm not strictly against it either.

But we should make sure that the "Text Attributes" dialog can be easily accessed. That is currently not the case. For example:
It is missing in shape context menu in Impress (it is there in Writer).
It is missing in the toolbar "Drawing Object Properties" in Writer.
It is missing in the "Drawing" toolbar in Writer.
It is missing in the "Drawing" toolbar in Impress.
It is missing in the Sidebar.
It has no direct item in the Format menu, but you need to open the item "Text Box and Shape".
Comment 4 ddminnl@gmail.com 2023-10-31 21:30:56 UTC
I'm unsure, but I think you're missing the point of my original submission.  It's not a bug, so there's no failure to reproduce.  And, it's not a question of whether the text area fills the shape by default, which it does.

My observation is that the text area box should be movable and resizable by mouse and/or keyboard without having to resort to a context menu selection.

Currently, adjusting the text box position requires at least one and likely multiple invocations of the Text Attributes dialog to get a desired spacing effect.  My best example of the need for a new behaviour is the placement of the text box on a connector between two vertically arranged flow chart elements.  After placing the connector and double-clicking the connector to enter text, the resulting text box appears centered over the connector.  I resort to the Text Attributes dialog to move the text off the line.  If my spacing value estimation is incorrect, I have to re-enter the dialog (another right-click, select Text Attributes, change a value, click OK).

Just let the user click-drag the text box.

TBH, in version 7.6.2.1, I cannot reproduce the original text positioning behaviour that forced me to adjust text placement on any multi-line flowchart object text box.  The text box now appears better placed initially.

If you're discussing something else entirely, my apologies for interjecting :-).
Comment 5 QA Administrators 2023-11-01 03:14:25 UTC Comment hidden (obsolete)
Comment 6 Heiko Tietze 2023-11-03 07:29:45 UTC
(In reply to Regina Henschel from comment #3)
> ODF allows to move or resize the text-areas rectangle, but we would leave
> the preset geometry of the shapes then. Using the preset geometry is
> essential for a good round-trip with ppt and pptx formats.

(In reply to ddminnl@gmail.com from comment #4)
> ...text box on a connector between two vertically arranged flow chart elements.
> ...the resulting text box appears centered over the connector.

I can follow the use case. It could solve or rather be a workaround for bug 45028 and bug 75301 (text becomes strike-trough and placing the label at connector points).

Would the position be fix once the text box has moved out of the object, meaning resizing and moving the parent has no effect on the label, or is it kind of an offset and the label moves with the parent?
Comment 7 Regina Henschel 2023-11-03 08:51:28 UTC
Text on connectors is different from text on flowchart shapes. The text area of the connector is always the bounding box of the connector. Move the connected shape around to see the problems.

Text for connectors would need a feature, that you can bind a text box to the start or end of the connector.

Text on connectors is not exported to pptx, because pptx does not know text on connectors.
Comment 8 Heiko Tietze 2023-11-03 08:55:41 UTC
(In reply to Regina Henschel from comment #7)
> Text on connectors is different from text on flowchart shapes.
So you argue to resolve as wontfix (and to improve the connector stuff elsewhere)?
Comment 9 Regina Henschel 2023-11-03 11:47:04 UTC
(In reply to Heiko Tietze from comment #8)
> (In reply to Regina Henschel from comment #7)
> > Text on connectors is different from text on flowchart shapes.
> So you argue to resolve as wontfix (and to improve the connector stuff
> elsewhere)?

I think, it is a valid enhancement request, to be able to change the values of "Line Spacing" be dragging something. This could be added in the UI of any shape which has "Text attributes" and might be also useful for the "Padding" in frames. Only moving or resizing the text area as whole should not be done. Therefore I would be more precise in the subject line, that this is about the "Line Spacing".

I want to warn, that such new feature will not solve special problems with texts on connector shapes. But we need no new bug report for these; bug 123934 and bug 75301 cover already problems with text for connector shapes.
Comment 10 Heiko Tietze 2023-11-08 15:14:55 UTC
(In reply to Regina Henschel from comment #9)
> I think, it is a valid enhancement request, to be able to change the values
> of "Line Spacing" be dragging something.
Do you agree with this, ddminnl?
Comment 11 ddminnl@gmail.com 2023-11-09 03:12:59 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Regina Henschel from comment #9)
> > I think, it is a valid enhancement request, to be able to change the values
> > of "Line Spacing" be dragging something.
> Do you agree with this, ddminnl?

Basically, yes.  Dragging a handle (to resize) or dragging a border (to move) the text box associated with a shape, including a connector, would address my enhancement request.

Thanks for your consideration.
Comment 12 Stéphane Guillou (stragu) 2023-11-09 08:57:28 UTC
Created attachment 190738 [details]
mockup

(In reply to ddminnl@gmail.com from comment #11)
> (In reply to Heiko Tietze from comment #10)
> > (In reply to Regina Henschel from comment #9)
> > > I think, it is a valid enhancement request, to be able to change the values
> > > of "Line Spacing" be dragging something.
> > Do you agree with this, ddminnl?
> 
> Basically, yes.  Dragging a handle (to resize) or dragging a border (to
> move) the text box associated with a shape, including a connector, would
> address my enhancement request.
> 
> Thanks for your consideration.

I think Regina argued that allowing a resize or move of the _text box_ itself is a bad idea and will create compatibility issues.
What she said could be done is having handles/borders that allow interactively changing the _spacing to borders_ values that are in the Text Attributes dialog > Text tab.
But ultimately, this has the same effect as what you are asking for.

Distinguishing text box boundaries from the "spacing to borders" boundaries in a good way might be the design challenge. In my opinion, the static text box boundary should remain visible (to denote how far the "line spacing box" can go), but should be thinner and somehow denote its "immutability".
Comment 13 Heiko Tietze 2023-11-09 10:39:19 UTC
Thanks for the summary, Stephane. That's what I understood too.
Comment 14 ddminnl@gmail.com 2023-11-09 17:14:09 UTC
Thanks for letting me chime in but, unqualified as I am, I cannot speak to any underlying issues, compatibility or otherwise, or coding solution that might addresses my suggestion's implementation.  I leave those in your collectively capable hands.  I guess I'm dismayed that a shape's text element is not more of an independent object.

However, it seems that regardless of what you call it, whether "changes to spacing-to-borders" or something else, the end result should be the ability to reposition and resize a shape's text box by mouse drag and/or keyboard shortcut (e.g. a post-selection left/right/up/down arrow to move the box).

If a behind-the-scenes change to spacing-to-border is the only way, then it's the only way. :-)