Text in a frame resizing by doubleclick results weird

[abra100pro]

Hello, Title and a short video says it all.

[MikeTO]

Could you copy one of those text frames that is giving you trouble to a blank document and upload it here so we can take a look at it? Thanks.

[thomaso]

The different behaviour depends on your current text overflow setting.

= works as you seem to want.

= sets frame height to "next" visible line or paragraph.

Concerning the frame width / vertical frame edges, I wonder what you would expect? Horizontally, the frame is always filled to its edges for at least 1 line, so what should happen and how would the app know which frame width you might prefer? In fact, Affinity adjusts the frame width depending on the current frame height, so that the frame is then filled with text not only horizontally but also vertically.

[Old Bruce]

The width double click seems to be taking information from the current height of the frame plus the amount of text in the frame.

I have to say that this double click feature has always struck me as a gimmick. 

[thomaso]

In addition to the mentioned text overflow setting, both, vertically & horizontal auto-adjust-click-behaviour is a feature rather than an issue. Horizontally its use becomes more obvious if you force the text width smaller than its frame width by manual breaks, creating horizontally empty areas this way. For instance:

[abra100pro]

On 2/18/2022 at 8:51 PM, Old Bruce said:

The width double click seems to be taking information from the current height of the frame plus the amount of text in the frame.

I have to say that this double click feature has always struck me as a gimmick. 

Sure, please find it attached.aPub-txtBlock.afpub

[abra100pro]

On 2/18/2022 at 9:00 PM, thomaso said:

In addition to the mentioned text overflow setting, both, vertically & horizontal auto-adjust-click-behaviour is a feature rather than an issue. Horizontally its use becomes more obvious if you force the text width smaller than its frame width by manual breaks, creating horizontally empty areas this way. For instance:

I love the double click feature and use it a lot. However in my little mind the result in both cases should be the one on the lower right. Why would I want to have the text be squeezed like that in the upper right? What is the rule of this squeezing? Commas? Periods? Line-breaks? No, it's a wild, unpredictable mix. Unless I oversee a secret pattern - was never good at crossword puzzles...

[abra100pro]

On 2/18/2022 at 8:44 PM, thomaso said:

The different behaviour depends on your current text overflow setting.

= works as you seem to want.

= sets frame height to "next" visible line or paragraph.

Concerning the frame width / vertical frame edges, I wonder what you would expect? Horizontally, the frame is always filled to its edges for at least 1 line, so what should happen and how would the app know which frame width you might prefer? In fact, Affinity adjusts the frame width depending on the current frame height, so that the frame is then filled with text not only horizontally but also vertically.

Thanks for the info. I made a short movie - faster and more efficient than writing and missunderstanding.

[thomaso]

2 hours ago, abra100pro said:

However in my little mind the result in both cases should be the one on the lower right. Why would I want to have the text be squeezed like that in the upper right? What is the rule of this squeezing?

The rule is 1. the frame height and 2. the text. It breaks after words or punctuation marks, as it normally does automatically to make the text fit a certain frame width.

A use case could be a layout where the frame height is more important than the width for some reason. For example, small ads in a magazine that need a certain height according to the layout grid and should avoid empty horizontal areas. So one would be charged by the width required, just as you often pay for the height of your ad within a certain column width.

Another use case could be a tabular layout, e.g. a story with the approach to fit as many years as possible into a certain horizontal area. This can be useful on an exhibition wall, for example, to be able to enlarge the text blocks within a certain wall width.

If you want to avoid horizontal text adjustment when double-clicking on a vertical frame node, first use the feature on a horizontal frame node, e.g. bottom centre, to adjust the frame height to the required lines of text. Then clicking on a vertical node does not affect the text flow / wraps, but only adjusts the frame width.

Aha, this seems to work "in general", but obviously it does not work 100% reliably. In this sample the word "sunt" gets moved to the next line, for no obvious reason. This could mean that there is an algorithm at work that tries to achieve an "optimal" width (= less empty space).

So I agree, it appears strange if we really can not use this feature to click-adjust the frame width without altering the text flow. Maybe a Serif moderator can shed some light on this?