Text wrap offset

[Like, would like more if…]

I'm having difficulty with text wrap. I'm using a rectangle that expands as a header and "pushes" the content of the main box away by a set distance. However despite having no style sheets using baseline grid, no baseline grid set and Ignore baseline grid selected I cannot get the offset to match my chosen distance. What happens is the text moves away relative to the leading of the text regardless. Pushing the offset up and up nothing will move until the next full line of leading value is exceeded, and will then jump.

If you look at the two sample files you will see the difference Affinity orange header boxes has only 2 outcomes, InDesign file (Green headers)

Outcome I was after is that of the InDesign file with the text beneath being exactly as the wrap is set – is this a bug or chosen way of working?

has incremental increases.

[loukash]

Hard to tell without inspecting the example document.

[Like, would like more if…]

Meant to add after doing the visuals from InDesign… please feel free to add a solution if there is one! Thanks.

Text wrap test.afpub Text wrap test.indd

[MikeTO]

I think this might be a bug. Either that or my brain isn't working because it's too late. 🙂 

I tried creating my own document and duplicated the issue with it. Text wrap seems to force text to start on the next baseline of the grid even when the baseline grid isn't in use.

I also tried it in v1 and got the same results.

[Old Bruce]

Same result as MikeTO. Same conclusion about the forcing to the next baseline, except that it is obviously not aligned to the baseline. I set up a 1 point baseline and the offset would honour that.

Myself I would probably just use a Text Frame offset instead of the text wrap. But that won't work if you have need of many different sized header objects. If it is actually text in the upper frame I would use Paragrph Style Decorations and Space after. Just do away with the second text frame altogether.

Definite bug though.

[walt.farrell]

I saw the same inexplicable behavior, so it's apparently on both Windows and Mac. It will be interesting to learn what the problem is, if someone figures it out.

[Like, would like more if…]

I have found a workaround, can only assume baseline grid in text boxes and baseline grid in document are getting themselves crossed over somewhere. I don't think this work around should be necessary and still consider there's a bug in here somewhere but you may find it handy. 

What I did to make this work is to use the "Independent baseline grid" in the text frame settings and set to "1pt Grid Spacing" (as per Old Bruce's document baseline test). If absolute accuracy is required then the smaller you make the baseline grid the better. 0.1pt is seemingly the smallest you can go (steps of 0.0353mm). Technically you could get away with only having baseline grid setting set for first paragraph.

Caveat: It does require that the paragraphs in the box are set to "Align to Baseline Grid" otherwise they will continue to space as before. And you need to make sure you uncheck "Ignore Baseline Grid" in the Text Frame settings > General, inorder to enter values for the independent grid.

[loukash]

On 2/10/2023 at 5:11 PM, Like, would like more if… said:

is this a bug or chosen way of working?

As far as I'm concerned, the Affinity method feels correct to me, while InDesign apparently got it wrong. (But I'd have to reboot to El Capitan first to check out how exactly my ID CS5.5 does it.)

My reasoning: Affinity simply respects the text frame settings. It shouldn't make a difference if you push the first line of a paragraph or if your wrapping object is somewhere in the middle of a paragraph, it should always keep the initially given leading intact, based on Top Inset and Vertical Position attributes.

The "Distance From Text" is simply the minimum value.

[Like, would like more if…]

19 minutes ago, loukash said:

As far as I'm concerned, the Affinity method feels correct to me, while InDesign apparently got it wrong. (But I'd have to reboot to El Capitan first to check out how exactly my ID CS5.5 does it.)

My reasoning: Affinity simply respects the text frame settings. It shouldn't make a difference if you push the first line of a paragraph or if your wrapping object is somewhere in the middle of a paragraph, it should always keep the initially given leading intact, based on Top Inset and Vertical Position attributes.

The "Distance From Text" is simply the minimum value.

In the original post Affinity doesn't honour this. If you have an offset of text that is "Not" aligned to baseline grid it should offset by the users chosen distance and not in steps defined by the leading of the paragraph. As discovered by Old Bruce even if you set the document's baseline grid to 0.5pt this behaviour persists (which it shouldn't as the first line should align to a 1pt accuracy) and the paragraph remains shifted by steps directly related to the leading of the paragraph and not baseline grid intervals. Screen shot of InDesign (green boxes) has been the same since CS5 - not that I have that anymore - but has been a method I have used for many years and is how it currently behaves too (CC). Not worth firing up CS5 for Loukash!

[MikeTO]

1 hour ago, Like, would like more if… said:

What I did to make this work is to use the "Independent baseline grid" in the text frame settings and set to "1pt Grid Spacing" (as per Old Bruce's document baseline test).

That's a good workaround.

22 minutes ago, loukash said:

As far as I'm concerned, the Affinity method feels correct to me, while InDesign apparently got it wrong. (But I'd have to reboot to El Capitan first to check out how exactly my ID CS5.5 does it.)

My reasoning: Affinity simply respects the text frame settings. It shouldn't make a difference if you push the first line of a paragraph or if your wrapping object is somewhere in the middle of a paragraph, it should always keep the initially given leading intact, based on Top Inset and Vertical Position attributes.

The "Distance From Text" is simply the minimum value.

I'm not sure I understand. The issue is even if baseline grid is off in the document and the frame, the baseline of text is aligned to the frame's baseline grid, if the grid existing and was set to the leading value. In this screen recording, the "Four" line should be immediately below the rectangle and not aligned to the neighbouring "Five" line in the text frame to the right.

 

 

[Like, would like more if…]

13 minutes ago, MikeTO said:

I'm not sure I understand. The issue is even if baseline grid is off in the document and the frame, the baseline of text is aligned to the frame's baseline grid, if the grid existing and was set to the leading value. In this screen recording, the "Four" line should be immediately below the rectangle and not aligned to the neighbouring "Five" line in the text frame to the right.

What you are demonstrating is of course correct behaviour, i.e leading remains the same when "wrapping" around something. Going back to the original post this is not about runaround within the copy but distancing copy from the base of an object set above it. Maybe because I'm trying to cheat a data merge issue and create an expanding title box that when it grows with double line content will push the content of the box of text to a specific offset I am confusing the issue. My work around works for this very specific issue 🙂. Thanks for indulging me.  

[loukash]

36 minutes ago, Like, would like more if… said:

Not worth firing up CS5 for Loukash!

Oh, it was definitely worth it!  
Because here's why I always – ever since ID v2.0 – felt there's something wrong with the ID method:

Compared to APu:

Consistency matters.™

[MikeTO]

I agree it looks better in APub but IMO it's wrong. If I want the text baselines to line up then I should use the baseline grid. Text wrap shouldn't ever pad by more than I specify.

It's not just ID that doesn't add unrequested padding, it's MS Word, Pages, Quark, etc.

[loukash]

11 minutes ago, MikeTO said:

Quark

Yep, the same inconsistency:

 

In other words, I, for one, wish no change to the current APu behavior in this special case because its result is exactly predictable based on the position and settings of the text frame.

That all said, unfortunately there are quite a few other problems with text frames, baseline grids or wraps elsewhere. I vaguely remember having posted several such issues before, and just recently I noticed that they're still not fixed in v2.

[Old Bruce]

On 2/16/2023 at 5:20 AM, Like, would like more if… said:

Maybe because I'm trying to cheat a data merge issue and create an expanding title box that when it grows with double line content will push the content of the box of text to a specific offset

I would use one text frame and two Paragraph styles for this Data Merge situation. The Header Paragraph Style would have a Decoration and an appropriate space after it. the Other Text Paragraph Style would be set as required. Make the Fields for the Header use the Header style and for the Other Text use the Other Text.

[MikeTO]

I don't normally use text wrap but I was making something fun today and was bitten by this bug today. The worst part is that when the bug is fixed then existing documents will change unless Serif adds code to recognize old documents and accomodate them.

[MikeTO]

Could this issue be reviewed? I experienced it again today and spent quite a while figuring it out only to realize I'd figured it out a year ago. While looking for it, I found others had reported it, too:

https://forum.affinity.serif.com/index.php?/topic/98227-text-wrap-issue-with-text-at-bottom-or-top/

https://forum.affinity.serif.com/index.php?/topic/93922-text-wrap-moves-away-text-by-lines-only/

https://forum.affinity.serif.com/index.php?/topic/102572-text-wrapping-doesnt-work-correctly-with-pasted-metafile-graphics/

https://forum.affinity.serif.com/index.php?/topic/195550-publisher-uses-baseline-grid-even-though-it-is-disabled/

In the first link above, Jon P stated five years ago that it was intentional behaviour. This isn't how InDesign, Quark, Word, Pages, and most other apps work with baseline grid off. In other apps, if there's no space above or to the sides of the wrapped object, the first baseline is offset from the bottom of the object by exactly the entered value.

In Publisher, it feels random because it sets the first baseline as if there were lines of text with the same leading from the top of the frame and it jumps in increments of that leading as if there was a baseline grid. It makes the user feel like the entered value is ignored. In Word, it only measures from the top of the frame if there is space for text on the left or right side of the wrapped object.

Thank you

Publisher:

 

Word - it will work this way if set to Square or to Top & Bottom, but with Tight it will work more like Publisher