Bug 156994 - Can't have text area shape the same as the drawing object's area shape
Summary: Can't have text area shape the same as the drawing object's area shape
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DTP
  Show dependency treegraph
 
Reported: 2023-08-29 21:35 UTC by Eyal Rozenberg
Modified: 2023-10-02 20:29 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of a rectangular vs shape-fitting text area (32.53 KB, application/vnd.oasis.opendocument.presentation)
2023-08-29 21:35 UTC, Eyal Rozenberg
Details
Example of a rectangular vs shape-fitting text area (34.48 KB, application/vnd.oasis.opendocument.presentation)
2023-10-02 20:22 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2023-08-29 21:35:17 UTC
Created attachment 189234 [details]
Example of a rectangular vs shape-fitting text area

This bug is about drawing objects such as circles, ellipses, rhomboids, stars, clouds etc.

When we type text into such a shape, the text area has a _rectangular_ shape - which is not at all the shape of the object we are trying to fill with text.

Now, it's true that _sometimes_, a rectangular for the text area can make sense; but generally - the text area shape should have the same shape as the drawing object (with a margin of course, but that is already configurable).

In practice, the ask here is for this to at least be an option: For every relevant drawing shape (e.g. not a line), the user should be able to decide whether they want a rectangular text area or one that fits the object shape.

I would even say that the latter should be the default; but if it's at least an option then that would already be a significant improvement.
Comment 1 Regina Henschel 2023-08-29 22:16:17 UTC
We can take it as enhancement request. But for me it is a "wontfix".

The custom shapes are defined to have very good compatibility to shapes in OOXML and MS binary formats. And there the text area is always rectangular. You can set size and position of the text area and you can rotate the area, but it is always rectangular.

When you want, that the outline of the shape bounds the text, then use another type of shape. Legacy rectangles and ovals, polygons and Bézier curves, all have the property "Adjust to contour". Only that its rendering is currently broken, see bug 152906.

When you convert a custom shape, e.g. a star, to a polygon or Bézier curve, then do it before you enter the text, otherwise the text will become curves too.
Comment 2 Eyal Rozenberg 2023-08-29 22:39:44 UTC
(In reply to Regina Henschel from comment #1)

Regina, I believe you're approaching this from a problematic perspective, which is over-adherence to MS Office conventions. If MSO has some quirk or bug, or is missing a feature - we should not adopt this flaw as well in the name of compatibility. Certainly, we should probably support MSO-like behavior as an option, and enable it when importing MSO content; but we shouldn't enshrine and enforce such faults.

The same goes for this issue. Microsoft decided to only offer rectangular text areas. Ok, they were lazy (or had other priorities). And we kind of got used to it over the years, since that's how things were in MSO. But that's not what the unbiased user would expect: They would (rightly) consider the choice of a rectangle for the text of a shape object to be arbitrary and gratuitous, as they have not indicated they want to limit the text or other content by some rectangular lines cutting through their circle or ellipse.


> When you want, that the outline of the shape bounds the text, then use
> another type of shape.

Note that we're talking about the opposite: The text should fit itself to the shape, not vice versa. Also, I'm not asking for help achieving this effect (for which your suggestion is good advice) - I'm asking for something to be doable without expending any special thought or effort, or at most the minimal amount of a toggle.
Comment 3 V Stuart Foote 2023-08-30 02:41:49 UTC
Don't see much utility to an enhancement to bound draw object text boxes with polygon or ellipsoid to match the object shapes.  Dev effort aside, it would be  a substantial detriment to OOXML and MS Binary file exchange/interoperability.

IMHO the status quo suffices and this => WF.
Comment 4 Eyal Rozenberg 2023-08-30 07:24:06 UTC
(In reply to V Stuart Foote from comment #3)
> Don't see much utility to an enhancement to bound draw object text boxes
> with polygon or ellipsoid to match the object shapes.

To say that, you need to refute my claim that this is the natural, and user-expected, behavior of text typed into a shape object. Otherwise - the current behavior is a bug, not an enhancement, and the utility of fixing it is that shapes would behave as expected and they should.

> it
> would be  a substantial detriment to OOXML and MS Binary file
> exchange/interoperability.

Wwhen the user chooses to have a rectangular text area, that would be perfectly interoperable; and MSO files will open just fine in LO. Beyond this - you're essentially arguing we should not ever improve the feature set and behaviors supported in out document formats beyond what MSO offers, because doing that means hurting exchange/interoperability.

> Dev effort

Indeed, implementing this would require a non-trivial amount of developer effort, it is not a minor tweak.
Comment 5 Heiko Tietze 2023-08-30 07:25:20 UTC
Very little benefit versus huge effort. While Draw sometimes is used as DTP software I'd recommend to use better suited tools.
Comment 6 Eyal Rozenberg 2023-09-11 12:57:18 UTC
(In reply to Heiko Tietze from comment #5)
> Very little benefit versus huge effort. While Draw sometimes is used as DTP
> software I'd recommend to use better suited tools.

This bug has nothing in particular to do with Desktop Publishing. It is purely about (unbiased/novice) user expectation.

If you let a user draw a circle or cloud or triangle, and type text in them, the assumption is that the text will fit the shape. Or at the very least - it would be exceedingly easy to have it fit the shape.
Comment 7 Stéphane Guillou (stragu) 2023-09-29 23:30:14 UTC
As it is possible to wrap text in parallel around a custom-shape's "contour", I can see how users could expect to be able to do something similar _inside_ the shape.
And I can't see why someone shouldn't be able to work on this feature if they wanted to.

But seeing the previous comments, given the workaround Regina mentioned, and given that I found it hard to find questions from users looking for such a feature (I thought I would easily find a link to put in the URL field), I think this is low priority.
If this is ever implemented, please:
- make the feature optional, and
- do not make it the default, for compatibility's sake
Comment 8 Eyal Rozenberg 2023-10-02 20:22:55 UTC
Created attachment 189963 [details]
Example of a rectangular vs shape-fitting text area

Made the comparison between the two kinds of shaping of text more apples-to-apples (same font color, same alignment, similar length of text).
Comment 9 Eyal Rozenberg 2023-10-02 20:29:01 UTC
(In reply to Stéphane Guillou (stragu) from comment #7)
> As it is possible to wrap text in parallel around a custom-shape's
> "contour", I can see how users could expect to be able to do something
> similar _inside_ the shape.

Actually, it's deeper than that. If you're not used to MS Office (or existing LO behavior), I claim user will expect not just to be _able_ to do this, but for this to be the default. If the shape is an ellipse, than the text should be bounded by the ellipse (possibly with some margin).

> > given that I found it hard to find questions from users looking for such a
> feature 

You have found it hard because office suite users have it drilled into our heads that text in shapes fits inside a rectangle. It is actually not uncommon that fundamental bugs don't get reported for years, because people encounter them on day one of using the software, get used to them, and forget they may have wanted something else. We've had this a bunch of times w.r.t. RTL bugs.

> I think this is low priority.

So, here's the thing. In the sense that people are used to this - you're right, it is low priority. But if you think about what newbie users expect - I would say it's high priority that we change the default.

> If this is ever implemented, please:
> - make the feature optional, and
> - do not make it the default, for compatibility's sake

Again, I'm arguing that the current behavior is a bug. It's an MSO-compatible bug, but a bug nonetheless. I claim this needs to be the default, with the current behavior used for compatibility (i.e. when opening MSO documents, or if this is introduced in an ODF version, then opening older versions would default to the text-area-is-rectange choice).