Affinity Publisher — In text frame with overseted text, only Out port (Text Flow button) should be marked red not both

[bbrother]

App: APub version 2.3.1
OS: Windows 10 Pro (22H2 compilation 19045.3930)

In APub there is an In port and Out port (so called Tex Flow buttons) which are used to make connections to other text frames.
They are used also to indicate if there is overseted text in text frame. 
These buttons are incorrectly marked when text is overseted.

The problem 1 (bug):

In standalone text frame (not linked to other, not in sequence of linked text frames) with overseted text both In and out ports (so called Text Flow buttons are marked red). And this is worng. There is no text Flowing In so the In port shouldn't be marked red.

When there is overseted text in such text frame only Out port (lower right) should be marked red with an eye icon indicating that there is more text to be placed but the frame is to small.

What is happening in APub (Problem 1)

What is expected. (only lover right Out port aka Text Flow button should be marked red) 

Problem 2(bug):

In sequence of linked text frames that contain overseted text, the In port (upuuer left Text Flow button) in the first frame in the sequence is marked as circle with red border. But this is also wrong.

The in port is an indication of begining of a story in case of sequence of linked frames with overseted text and shouldn't be marked as circle with red border. It should be displayed as trinangle with blue border like for unlinked text frame.

What is happening APub (Problem 2)

What is expected

 

 

[Dan C]

Hi @bbrother,

Thanks for your report!

I can confirm that both of these behaviours are expected and by design. 

1 hour ago, bbrother said:

In standalone text frame (not linked to other, not in sequence of linked text frames) with overseted text both In and out ports (so called Text Flow buttons are marked red).

The reason that both triangles are marked in red for a standalone overflowing frame is that either handle can be used to 'flow' the text to a different frame. Therefore these triangles change from blue (when not overflowing) to red (when overflowing), but both can be used to reflow the text.

 

1 hour ago, bbrother said:

In sequence of linked text frames that contain overseted text, the In port (upuuer left Text Flow button) in the first frame in the sequence is marked as circle with red border.

Again, the reason this handle changes from blue to red is to indicate that text within the story flow does not fit within the current frame(s). The reason this is shown as a 'dot', rather than a 'triangle' is due to the specific text frame not being selected.

If you have 3 frames in a flow sequence, the selected frame will show a 'triangle', the unselected frames will show a 'dot'. 
If you have none of these frames selected, all will show the red 'dot' icon.

As above, the left hand handle is designed to also shown in red, as it can be used to flow the text to the left of the frame.

 

Finally, these text frames show red handles on both sides for all frames, throughout the full text flow when the text is overflowing to provide clear feedback to the user that their text may not be fully visible and therefore may not be exported etc. Removing one side of these red icons can reduce visibility of the issue to the user.

I hope this clears things up

[bbrother]

@Dan C Thank you for the extensive explanations with attached videos. I appreciate your effort

To say that this is a rather unconventional (not intuitive) approach to linking text frames and using text flow buttons is an understatement.

I wouldn't be myself if I didn't ask.
Why not keep it simple and intuitive. Why so many varieties of icons (circles, red triangles, blue triangles), text flowing to the left of the frame.
You could sing all day why, oh why, Serif, did you do this to me 

1 hour ago, Dan C said:

Removing one side of these red icons can reduce visibility of the issue to the user.

I do not agree with that. The text flow buttons could be enlarged as they are currently very small to prevent this.

[Dan C]

No problem at all!

Unfortunately I can't speak for the developers explicit decision making here, simply reiterate that the current behaviour is as they intended it.

In the meantime, I'll move this thread to the Feedback section for our team to see and consider your changes in a future update