Text wrap behaving oddly with master pages

[thothsscribe]

As shown in the video, I am very confused as to why the text isn't wrapping properly when I 'edit detached' the height of an object that is created on the master page. 

[walt.farrell]

Purely a guess: You're not adjusting the height of a Text Frame. You're adjusting the height of a Group, which happens to contain several Text Frames.

I suspect it would work if you were to actually adjust the height of one of the Text Frames.

[thothsscribe]

The thing is that when I edit the master I am editing the grouped set of objects and the text is wrapping perfectly. I edit the same object on a spread and its not responding the same at all. 

[thomaso]

Walt, doesn't your assumption depend on the layer which has the text wrap assigned? Could be the group, the gray rectangle, or one of the text frames, right?

thothsscribe,
I can't replicate it here, I don't get such a difference of text wrap between master and document page.

– Can you upload a slim .afpub with the objects of the master frame?

[thothsscribe]

Here it is! Thanks for all the help. slim debug file.afpub

[walt.farrell]

11 hours ago, thomaso said:

doesn't your assumption depend on the layer which has the text wrap assigned?

My interpretaion of the question is that @thothsscribe is talking about the text not properly reflowing within the group, not about how text wraps around the group. But perhaps I misunderstood.

[thomaso]

The wrapping issue appears to happen because it's applied to the entire group AND the layers inside the group were edited (e.g. frame heights) AFTERWARDS. It seems to get fixed if you remove + and re-assign the wrapping for the group after finish editing its layers.

Another approach would be to apply Text Wrap not to the group but to the background Rectangle only. Therefore you would exclude all text frames inside the group from wrapping, this gets activated in the Text Frame Panel. Note that you need to adjust this layer's height individually anyway, while changing the group's height would influence the containing layers, too, e.g. vertical distances inside the group (as shown in your video).

In the attached .afpub your document page 2 appears to work correctly now, I only did deactivate/activate text wrap for the group.
I also added two master pages for comparison, one has the wrapping applied to the group, the other to the background rectangle.

slim debug file _2.afpub

[thomaso]

1 hour ago, walt.farrell said:

is talking about the text not properly reflowing within the group,

I think the text frames inside the group do reflow correctly. In the video the group gets changed in height, which of cause will also influence the text frames inside in both their individual height AND their vertical distances to each other. Since they are set to show, not hide their text overflow the video shows text as moving which may appear as reflow caused by Text Wrap – but indeed isn't.

[thothsscribe]

@thomaso is correct that I am concerned about the text wrapping around the ingredients objects. 

 

And the turn off wrap and turn it back on solution does work! Which is the simplest solution. Thank you for that. I will also have to mess with the box only format. Do you feel there is one that is recommended over the other? I am very new to print design. Familiar more with vector sort of stuff. 

[thomaso]

11 hours ago, thothsscribe said:

I will also have to mess with the box only format. Do you feel there is one that is recommended over the other?

Yes, the Text Wrap applied to the single background "Rectangle" layer. I wouldn't apply Text Wrap to a group if I want to edit the group's object sizes afterwards.

EDIT: it appears to work in general if a group layer on a master page, which has the text wrap assigned, gets its content changed on a document page. So the following, greyed-out assumption was not quite correct, though there may be issues with sub-grouping (see next post)... I doubt the Text Wrap feature was designed to work with such a flexibility, kind of being live-synced for both sides: for the wrapping object AND the wrapped object, if it is applied to a group of layers. It would require a permanent live-check of the dimensions of all involved objects inside the group, this would not appear to me as an efficient use of APub's computing resources. That is why you have to switch it off + on again: to run this check and get the wrapping calculated. – So I would call this occurrence neither a missing feature nor a bug.

I probably would not place this group on a master page at all, simply to avoid the need of detaching on every page. Instead a simple copy/paste will work, too, or its use as asset. It would give you easier access to the objects, e.g. to delete unused text frames and adjust heights, which seems to be necessary for each of its uses. By the way, I'd recommend to use a K-only colour for gray or black text, instead of your current RGB, it will result in sharper prints, especially for thin types, because only 1 of 4 inks gets used.

Edited August 16, 2020 by thomaso

[thothsscribe]

What I don't get is that on the Master page it behaved exactly as I expected. Stretching and shrinking and the text wrap worked. It was only when I edited detached that the behavior just wouldn't update. And the reason I did do it on the master was just for the locked in positioning and if I update the color or type it will update almost everywhere. So far, relative to tools like Figma, I am not understanding how an 80+ page recipe book won't become horribly out of sync page to page if you have to change almost any non text element. Using an Asset for the ingredients or copy paste it, if I decide to change the background color on the element I will need to do it on every page. Other design tools seem to handle that very simply with symbols.

[thomaso]

After a test with master groups + text wrap it still seems to cause issues if Text Wrap is applied to a group which contains further sub-groups which get their content changed. It feels as if the text wrap chain gets kind of interrupted by sub-groups if only the parent group has text wrap assigned. Then the workaround to unassign + reassign text wrap to the parent group after changes done to sub-sub-layers seems to be necessary.

Aside those groups and sub-groups I also assume (don't really know) that the issue with your document would also be related to the way the layers and groups are currently organised and how they were created. Note the lack of the orange master markers at the left edge of some layers in the according group. Most of the layers do show this orange, but two groups (part of the affected layout box with the gray background) don't show this orange bar and their containing layers don't, too. Possibly such layers don't have a clear state (master or not?) and maybe a reason to confuse the app – or at least the users.

This video shows first a few changes done on a document page to master groups in detached mode. On the left (red) the group has text wrap assigned, on the right (green) the text wrap is assigned to the items inside the group but not to the group. – At 03:49 min the video switches to your document, to the master page first. I ungrouped and regrouped the according layers, then the orange markers do appear. At 04:15 min I switch to the document page (which, of cause, looks chaotic now because of my changes on the master page and its already edited elements). But selecting the entire group now appears to maintain text wrap working.

To discuss your concerns with efficient workflows of changes in a 80-pg book you should rather use either the Questions or the Feedback Forum, not this forum, which is for Bugs only. Just two related keywords which you might want to look for:  "global colour" and "linked image".

[Gabe]

Hi all,

Issue now logged. It seems to be related to this other recent wrap issue, where applying wrap on a group clears any wrap settings already existing inside the group. 

[thomaso]

@Gabe, thanks for the info. Unfortunately I haven't noticed (or I don't remember?) a recent similar wrap issue.

Can you also give me a hint to the orange master markers? Can it be – in general – correct if a layer inside a master layer on a document page doesn't have an orange marker, or is every missed marker an indicator for an issue? So, should a marker be on every layer, even if a layer gets placed inside the master layer on a document page only, not on the master? I wonder because for those layers their master state seems unclear to me: though they are inside a master layer they are, of cause, not objects of the master page.

[Gabe]

When you edit detached, any objects you put inside the master will not have the "sync" marker. This is expected, as technically, that object is not part of the master, but only added locally for that page. Having a sync marker on it (even being it dotted) would be a false positive as it would indicate that at some point in time, that layer was part of a master. 

When you edit linked, you're editing the master as if you were to double click on it in the Master Page section. So, any objects you place inside the (Master) layer should now have the sync marker, and it should reflect on all pages. 

Hope this makes sense