Affinity Publisher 2.5.7 – Why does reformatting boxes break up words?

[LEB]

Hello everyone,

I still struggle to figure out why AP would behave as shown in the attached video upon double clicking.

LEB

[Hangman]

Hi @LEB,

Could you upload a document containing that exact text frame, feel free to remove everything else if it's sensitive...

The text frame has been scaled but that doesn't account for the behaviour you're seeing...

[LEB]

Hello @Hangman,

Here it is, same bug with Designer where I pasted the content.

LEB

affinity_reframe_bug.afdesign

[Hangman]

Hi @LEB,

The text is a single line with the text frame sized so that the three words appear on their own lines... I'm not entirely sure why when double-clicking to fit the text frame to the text it decides to wrap it as it does... I would have expected the text frame to shrink to the longest word, i.e., Acceptation...

If you add an 'S' to Publication, the resized text frame behaves as expected. Equally, if you add Soft Returns between the three lines of text, it behaves correctly.

Someone in the moderation team may be able to explain the behaviour but it doesn't feel quite right to me either...

[LEB]

Hi @Hangman, thank you for doing those tests!

[Hangman]

Hi @LEB,

No problem, I have a feeling I've seen the behaviour before but not really thought too much about it but it would be good to understand the logic of the current behaviour...

[MikeTO]

Double-clicking the right-centre size handle doesn't always work the way you or I would expect. This handle isn't documented in Help, only the bottom-centre handle is documented and that works as expected. I didn't document these features in my manual but I will do it now for the next version.

Here's how double-clicking the right-centre size handle sizes the frame to fit all the text in the frame:

1. If the frame is overset (overflowing) and the overset text IS NOT shown (the eye with slash icon), double-clicking will adjust the right edge of the frame narrower to match the rightmost character on any line. This is good.
2. If the frame is overset (overflowing) and the overset text IS shown (the eye without the slash icon), double-clicking will adjust the right edge of the frame wider so that all of the overset text fits into the frame. Note that if the frame is not the last frame in the story, it will work as above. This is good.
3. If the frame is not overset and there IS NOT vertical space for another line of text, double-clicking will adjust the right edge of the frame narrower to match the rightmost character on any line. This is good.
4. If the frame is not overset and there IS vertical space for another line of text, double-clicking will adjust the right edge of the frame narrower and wrap the text as required, to first match the frame's height and then match the frame's width, as shown below. This is that part that many of us are confused by because it's not useful - nobody would want their words to be broken at illogical places just to satisfy the requirement of first filling the frame vertically. IMO, this should be changed to match #1 and there would be no confusion. In the meantime, if you don't like this, the workaround is to first double-click the bottom-centre size handle before double-clicking the right-centre size handle. That will avoid this feature/bug.

Before/after double-clicking the centre-right size handle

  

[MikeTO]

Also:

• It would be nice if double-clicking the bottom-right handle would size a frame both vertically and horizontally at the same time.
• The Help page should really mention double-clicking the right-centre size handle: https://affinity.help/publisher2/English.lproj/index.html?page=pages/Text/fittingFrameText.html&title=Fitting text to frames

[LEB]

@MikeTO, excellent posts!

[Hangman]

19 minutes ago, MikeTO said:

In the meantime, if you don't like this, the workaround is to first double-click the bottom-centre size handle before double-clicking the right-centre size handle. That will avoid this feature/bug.

Unless I've misunderstood that doesn't appear to work with the sample file...

[MikeTO]

@Hangman Good catch, thank you.

In this example, double-clicking the centre-right handle scales the frame the way we would expect:

 

but in this second example, it does not. In both of these examples, we have the same number of characters and the first line is longer than the last line, but Publisher is scaling the frame as narrow as possible to contain the content, not to the longest line. IMO this is of no use and should be changed.

[Hangman]

10 minutes ago, MikeTO said:

In both of these examples, we have the same number of characters and the first line is longer than the last line, but Publisher is scaling the frame as narrow as possible to contain the content, not to the longest line. IMO this is of no use and should be changed.

As far as I can tell (though I've not tested extensively) the text wrap seems to ignore the first line but wraps based on the longest line after the first line...

Apologies for the Franglais in the screen recording...

[MikeTO]

17 minutes ago, Hangman said:

As far as I can tell (though I've not tested extensively) the text wrap seems to ignore the first line but wraps based on the longest line after the first line...

It's not ignoring the first line, it's just scaling the frame so that every character fits, without regard to where words should break. It is literally fitting the frame to the characters but not to the words.

[LEB]

As you indicated, @MikeTO, this behaviour does not make sense to me.

[Hangman]

21 minutes ago, MikeTO said:

It's not ignoring the first line, it's just scaling the frame so that every character fits, without regard to where words should break. It is literally fitting the frame to the characters but not to the words.

I was referring to the outcome after double-clicking the bottom handle followed by the right handle...

When the first line is the longest the process appears to ignore that but it seems to honour it when the second or third lines are the longest...

[MikeTO]

I think that's just a symptom of using a line composer instead of a paragraph composer. But if we reverse the algorithm we'll probably annoy somebody so I'm going to let this go. 🙂