Parent page overrides seemingly not working

[AndyGar]

Not sure if this is a flaw in InDesign or my memory going.

1. I have placed a text frame on the A-Parent, and added some text and set the font face to Arial and given it a fill colour (lets say Blue) and applied it to every page.
2. I then go to an individual page and Ctrl / Shift click on it to override and change the font fill color to a different color (orange).
3. Having done this go back to the A-Parent and alter the Font face for the text to something else (Time New Roman).
4. When I go back to the page which had the override applied I am now expecting the text to still be orange but with the new font face of Times New Roman, however it is still set to Arial while all the other pages have changed to Time New Roman.

Shouldn't editing the font face on the A-Parent pass through to this page, as I only overrode the font color?

Thanks, Andy

[Steve Werner]

When you override a frame on a parent page, you break the link to the frame on the parent page. Only by reapplying the parent page to the document page can it take on the parent page attributes.

[Steve Werner]

To clarify, I meant, "When you override a frame based on a parent page, you break the link..."

[AndyGar]

Hi Steve, For some reason I thought the link only broke if you actively detached the frame from the parent, but that an override simply overrode that individual property while still allowing the rest to be inherited from the parent (like with Para styles for example). 

Just out of interest if it breaks the link totally how does it differ from detaching the object then?

Thanks

[Steve Werner]

Overriding breaks the link to the parent's attributews altogether. It would get very complex is only meant, turn off certain qualities, but leave others on.

[AndyGar]

Hi Steve, 

Sorry if i'm totally misunderstanding this, but that doesn't appear to be what the Adobe help files say. They seem to say overriding works like it does with styles, and only deliberately detaching an overriden object would break the link. The below is copied from the help files:

-------------------

Override parent item attributes - Overriding a parent item puts a copy of it on the document page without breaking its association with the parent page. Once the item itself is overridden, you can selectively override one or more attributes of the item to customize it. For example, you can change the fill color of the local copy. After that, changes to the fill color on the parent page itself will not update to the local copy. However, other attributes, such as size, will continue to update because they have not been overridden on the local copy. Overrides can be removed later to make the object match the parent. Attributes you can override for a parent page object include strokes, fills, contents of a frame, and any transformations (such as rotating, scaling, shearing, or resizing), corner options, text frame options, lock state, transparency, and object effects.

Detach items from their parent - On a document page, you can detach (disassociate) a parent item from its parent. The item must be overridden on the document page, creating a local copy, before you can detach it. A detached item does not update with the parent because its association with the parent page is broken.

To detach a single parent item from its parent, first override it by pressing Ctrl+Shift (Windows) or Command+Shift (Mac OS) and clicking the item on a document page. Then choose Detach Selection From Parent in the Pages panel menu.

-------------------

It's taken from this page: 

https://helpx.adobe.com/uk/indesign/using/master-pages.html#override_or_detach_parent_items

That's certainly not how it's working though, as per the original question.

Thanks, Andy

[Steve Werner]

I can deny that that's how its defined in the Help file. However, it's very difficult to keep track of which attributes have been changed on the parent page and which on the document page, as you can tell from the complexity of the description, it's a complicated interaction. I usually treat the overridden item as "unlinked" because I can rarely keep track of such changes, especially if time has elapsed from then when I did the overriding.

I would choose choose Pages panel menu > Parent Pages > Remove all Local Overrides if I wanted to get rid of overrides on a page. 

[Scott Falkner · Accepted solution]

Perhaps content is not considered an attribute. You can change the stroke size or colour, fill colour, or effects. Those are attributes and the changes should propagate through to the overridden object. But changing the content (even attributes of content) is a kettle of fish of a different colour.

[AndyGar]

I think you are right Scott, good spot. Having had a coffee and re-read the Adobe files again it does specifically refer to "attributes you can override for a parent page object". There is actually no reference to text in there at all, everything it refers to is a feature of the object not the content.

[AndyGar]

Totally agree Steve, keeping track of the overrides would quickly become a nightmare as they don't appear to show up anywhere. I tried the story editor, properties panel and a few other places but nothing. Made me appreciate just how easy text style overrides are where you can just hover over the style and it tells you exactly what's hapenning. Thanks for the various suggestions.

[Steve Werner]

There is a current discussion going on among InDesign users in a different forum about how useful it would be to have a "parent page override highlighter." Suggested by David Blatner, in that discussion Anne-Marie Conception pointed out its advantages [both are founders of InDesign Secrets and active in Creative Pro Magazine]:

"When you view a doc page, frames that are from the parent page look different than the rest. That is good.
When you override a parent page item, the frame looks exactly the same as 'regular' frames. That is bad.

"1) Can we assign a special frame to overridden parent page objects?

"2) Or, View > Extras > Show Overridden Frames; which would put a heavy stroke around them and a light tinted background color behind them (like Show Assigned Frames does now)

"That removes a lot of the guesswork out of working with and troubleshooting parent page frames on doc pages.

Bonus would be a tooltip or the Info panel showing what has been overridden in the selection: Contents, Position, Frame Attributes."

[AndyGar]

I like the sound of option 2, I'll have to take a look at that thread. Thanks Steve.

[Milkrow]

As I recall, it used to be that if you placed text into threaded text boxes (housed on the parent page), that text would remain even if you reapplied the parent. Reapplying the parent would re-establish a linked (and empty) threaded text box on the document page, but the overridden text box (now filled with text) would not be alterred. They would be stacked (overridden box over linked parent page box).

However, today I've found that if I place text, then reapply the parent, the text is eliminated unless I expressly detach that box from the master. Yet, all other threaded boxes not explicitly detached are unaffected. What can happen is that if you reapply the parent and the attached text box reverts. Then the placed text disappears and it adds pages to flow the text which was previously on that page. That doesn't make sense. Once you place the text, it should persist unless you explictly delete that text box, even if the parent page is reapplied.

Does this mean one would have to select ALL the text boxes which now contain threaded text and manually detach them? I've tried detaching a text box first, but placing text won't auto flow to additional pages (such that you'd perhaps have a detached box on all the resulting pages).

What am I missing?

[rob day]

As I recall, it used to be that if you placed text into threaded text boxes (housed on the parent page), that text would remain even if you reapplied the parent.

Hi @Milkrow , Maybe you are thinking of Primary Text Frames?

https://community.adobe.com/t5/indesign-discussions/can-someone-help-demystify-how-primary-text-fram...

When you override a regular text frame the connection to the content is broken, but the frame’s other properties are connected until they are changed. Here I’ve overidden the text frame on page 4 and changed its stroke color. If I go back to the parent and change the frame’s stroke, fill, and x,y position, the fill and position on the pages change, but the stroke doesn’t:

[Milkrow]

Thank you Rob. I read through the other post (from 2017, egad!) and that makes it more clear, albeit still not intuitive. Perhaps I'm having trouble imaging the scenario when it would be desirable for text (flowed into a non-primary text box, parent page item) to be deleted if you reapply the parent. It doesn't delete that same text when the parent page is changed (e.g., A to B). Perhaps this is a use case scenario I've not encountered, and as long as all the other attributes on a parent page are accurately being reflected when changes are made (headers, footers, markerts, object attributes), then there may be no need to reapply (it's not sunscreen, after all). Yet, it sure would be unsettling to find your text gone from many pages when you reapply—you'd think you wouldn't get burned.

[rob day]

Yet, it sure would be unsettling to find your text gone from many pages when you reapply

It’s one of the the reasons for the Primary Text Frame feature.

Here my threaded text is through Primary Text Frames on the Parent. If I make some changes to a page primary text frame like moving the x,y position and changing the inset and fill color, that frame would no longer respond to a position and fill color change from the parent. But, I can reapply the parent and not break the textflow because it was created as a primary text frame:

If the text flow is through regular text frames, the threading is going to break when I reapply the parent because the page’s text frame is converted from a page item back to a parent item, which hasn’t been overridden, so the thread has to be broken:

[Milkrow]

Yes, I'm seeing that behavior, though, on occasion, frames I thought were primary are disappearing when reapplying the parent. Somehow I must have changed them. IF I can recreate that, I'll post back. Separately, I've been in the habit of holding the shift key to flow text to the end of the story which works with regular text frames as well as primary text frames on the parent (depending on how you created the primary text frame). When you create the primary text frame at the outset of creating a document (checkbox), then use the shift key when flowing text into on page one...it won't flow the text into that frame, rather, regular text frames are created on top. However, when you manually create the linked, primary text frames after the document has been created, something different happens. If you hold the shift key to flow the text, the text flows, but only onto the first right-hand-page, then subsequent left-hand-pages, but not the subsequent right-hand pages. Perhaps that is also the intended behavior, but not something I'd encountered until scrutinizing this issue.

[Milkrow]

And to be clear, I am aware that I don't have to hold the shift key to flow the full story into a primary text box; I tried both ways to see how they were different. Not holding the shift key worked fine.

[Barb Binder]

Hi Andy:

If you create a paragraph style to control the formatting, and edit the style, this will work the way you want it to.

~Barb

[AndyGar]

Hi Barb, the issue here is only overrides on parent pages, the paragraph styles are working fine. I've put a bit more detail in my reply to Steve above. Thanks, Andy

[Willi Adelberger]

Fonts are not changed via Master/Parent, they are only fixed via Text styles, Pargaraph and Charcter Style.