Masterpages are applied to spreads, not to individual document pages?

[Intuos5]

Hi,

I am working on a book layout for the first time using Publisher instead of Indesign and I came across a confusing case of how masterpages are applied. Say, I have two masters, one contains the chapter titles and the other uses regular text only. Now, if I apply the text master to the document page on the left and the master with the titles to the document page on the right, you can see that there's something odd happening with the numbering. That is because the Titlepage master also adds masterpage content (albeit invisible) to the document page on the left. Why is this happening? And is this a bug?  Though it also happens in Publisher 1.10.6....

See how the document is structured in the vid below:

And the file:

Master page item is applied to spread.afpub

 

The reason I am using masterpages for this is so that I can still add and remove pages during the process without having to worry whether a page is left or right facing. Doing so, I noticed many issues when I had first applied a master to a spread and then overwrote it with a master applied to a single document page (leading to double items on page and content migration issues). While the problem is obvious in the example below, it really wasn't with completely different masterpage designs.

 

 

[Intuos5]

10 minutes ago, anto said:

Even when you organize chapters on separate master pages, it doesn't work.

Damn, that's what I wanted to try as workaround. Okay, this means it is impossible to complete my work in Publisher... 😞

[Intuos5]

@anto Could you upload the file by any chance?

[Intuos5]

10 minutes ago, Horizon3 said:

@Intuos5 please can you share how you achieved to have your text bottomed so perfectly as you have. I am new to Apub and not sure how to achieve this yet. 

I have first determined the size of the text frame and then applied a baselinegrid to the document based on the planned text frame size. So if the text frame is x mm high, then the baselinegrid is x/ number of lines in the frame. If you calculate the dimension for a single line, you can set that up as baselinegrid dimension for the document or for a particular frame. If you set it up for the document, you can then use the baseline grid to snap all your contents to and base the sizes off of the baselinegrid.

[Intuos5]

@anto

I am sorry, but I still don't see what I am doing wrong here. I can't seem to get the result that you showed in your video. See:

So I have started with clean pages without masterpage items assigned. I manually toggle that the title has to be a list.

But, as soon as I apply the text page, the numbering for the 2nd chapter changes from 2.0 to 3.0.

You can clearly see this here:

You'd think this would be as banal as applying the masterpages in your document, but how can such a basic task be so hard (impossible for me) to accomplish?

 

[Intuos5]

1 minute ago, anto said:

Do not use Numbered list. Seems that this function creates problem. Write all chapters manually without numbered list.

Which means this should be considered a bug?

[Intuos5]

14 minutes ago, anto said:

You can use Section manager. It is easiest.

Well, if I use numbered lists to number footnotes and figures, those also get messed up. So this is not only a matter of numbering chapters. It's just an easy example. And yes, I do use the section manager. But I have both Parts numbers for the book (which I number with Roman numbers) and chapter numbers (which I number numerically).

[Hangman]

On 9/24/2023 at 2:47 PM, anto said:

Even when you organize chapters on separate master pages, it doesn't work.

Unless I'm missing something, this 'appears' to work correctly on macOS...

[Intuos5]

@Hangman have a look at topic:

What used to work fine in V1 for me doesn't work in Publisher 2.2.0 on Windows 10.

[Intuos5]

I do notice that the layer order has influence on the numbering, since my left items were above the ones on the right, that may have made a difference earlier. Just didn't realise it was the case (cut paste resolves it > 💡 by changing the layer order).

 

[Hangman]

11 minutes ago, Intuos5 said:

I do notice that the layer order has influence on the numbering, since my left items were above the ones on the right, that may have made a difference earlier. Just didn't realise it was the case (cut paste resolves it > 💡 by changing the layer order).

That would seem to make a lot of sense, hopefully that effetively resolves the issue as well...

[Intuos5]

It doesn't resolve all the issues, because any invisible text frame with a numbered list still increases the count of numbered lists that are visible.
E: What I do know now is that the order of applying masterpages affects the layer order and therefore affects numbered lists.

 

[Oufti]

What I found up to now, thereabout…

• Applying a master page on page is alike to "putting" its content, or content container like frames, on the page. You see it in the Layers panel.
So order matters in the same way as if you were adding "layers" (i.e. (group of) elements or objects) directly on the page. 

• If you apply a master on a page that already has content, this content can migrate from one layer frame to a new one above. When it does depends on different things: identical name, relative proximity or similar size of the frames,… 

https://affinity.help/publisher/fr.lproj/pages/Pages/migrateMasterPages.html

• It is not necessarily needed to pile multiple layers (even if sometimes it happens blindly); often it is better to choose to replace a master and migrate its content.

[Intuos5]

56 minutes ago, anto said:

It turns out that these are not numbered lists, but numbered frames. They do not depend on master pages at all. They behave very strangely. If you want to change the order of objects as you described, the numbering changes. And sometimes incorrectly.
This is probably a bug.

 

 

The main 'bug' likely is that applying a masterpage shuffles content around in the layer stack, hence the numbering changes. What you see in the vid that I quoted is that there is lag redrawing numbered lists applied across frames. If you make a numbered list in a masterpage and apply the masterpage across a long document, when you open the document it will likely take several seconds before you see the 1.0s turn into 2.0, 3.0, 4.0, etc. on your document pages. This doesn't mean that the list numbering is bugged, but that it takes time for Publisher to recompute the numbers.

[Intuos5]

5 minutes ago, anto said:

Are you serious? It's only 1 to 3 or 5. And what if there are 100?

Well, in my case it had to render the large images 24 megapixel images on those pages as well. But there definitely is a performance hiccup for the numbers.

[Intuos5]

Okay, @Dan C I am tagging you on this if that's okay.

Topic summary
We found 3 correlating bugs/ issues in this topic:
1. The order in which masterpages are applied, changes the layer order and thereby the order of (global) numbered lists that are applied per text frame (e.g. for image captions or titles). Instead, if you apply two masterpages to a document page, the left page master should always be below the right page master. In V1, some of the issues with the layer/ numbering order were not present, so it's a regression.
2. Numbered lists items take a while to recompute, so they appear to be buggy, whereas they in fact work as expected (after waiting a while and/ or triggering a page refresh by zooming).
3. If you apply the text style that contains numbered lists to masterpage text frames and apply different masterpages to a left and right page document spread, the invisible frames from a masterpage do end up adding to the numbered list counting, even though there is no way to tell they do (from a user perspective). It doesn't seem to matter whether you have enabled or disabled the numbered list within the text frame. As long as the style is present (even when the list is off: ), it ends up affecting the numbers in other text frames.

Do you want me to split this out or is this description + all the content in the thread clear enough to reproduce the bugs?

[Hangman]

45 minutes ago, anto said:

You haven't yet tested how the numbering behaves when you insert a new chapter between chapters instead of after.

[HCl]

.

[Intuos5]

3 minutes ago, Return said:

Didn't follow the complete thread but why are you using spread master pages to apply to single pages?
Why don't you use single page masterpages to apply to a left or right page?
 

That's what I am doing now, but it'll inflate my masterpage count by quite a lot, from 4 to 8 just for text pages, for instance.

E: The point is, if the software allows you to apply masters to pages, not spreads, I should be able to use it wothout any issues.

[HCl]

.

[Intuos5]

3 minutes ago, Return said:

And what's the problem? 

See summary post above and or the rest of the thread...

[Intuos5]

1 hour ago, Hangman said:

 

@Hangman, try to apply the Title page facing to individual pages and not to the spread. If you have the master applied to individual document pages, instead of to the entire spread, you may be able to see something else happening. You should have two different masterpage layers visible in the layers panel on for the left facing page and one for the right facing page. If you don't see any issues then, it means the issue is Windows specific.
The order of assigning facing master page spreads to single document pages matters, because you can see that this affects whether the left master is above the right master or not. If the left master is on top, the right master has a lower number. I feel like a broken record now for reiterating this one more 😅

 

[Hangman]

4 minutes ago, Intuos5 said:

@Hangman, try to apply the Title page facing to individual pages and not to the spread. If you have the master applied to individual document pages, instead of the spread, you may be able to see something else happening. If not, than the issue is Windows specific.

Applying the Title Facing Page to individual pages exhibits the issue you mentioned in your initial post, i.e., it takes its numbering from both master pages i.e., right-hand facing pages adopt odd numbers and left-hand facing pages adopt even numbers. I see the same behaviour in v1.10.6.

For me, this only works as expected using individual Left and Right Master pages...

[Intuos5]

12 minutes ago, Hangman said:

Applying the Title Facing Page to individual pages exhibits the issue you mentioned in your initial post, i.e., it takes its numbering from both master pages i.e., right-hand facing pages adopt odd numbers and left-hand facing pages adopt even numbers.

Thanks for confirming!

13 minutes ago, Hangman said:

 I see the same behaviour in v1.10.6.

For me 1.10.6 was more consistent, it didn't display all the same issues I have reported here.

13 minutes ago, Hangman said:

For me, this only works as expected using individual Left and Right Master pages...

That's the only way indeed to rule out any of these issues.

[stokerg]

On 9/27/2023 at 8:21 AM, Intuos5 said:

1. The order in which masterpages are applied, changes the layer order and thereby the order of (global) numbered lists that are applied per text frame (e.g. for image captions or titles). Instead, if you apply two masterpages to a document page, the left page master should always be below the right page master. In V1, some of the issues with the layer/ numbering order were not present, so it's a regression.

We are aware of this and do already have it logged.

On 9/27/2023 at 8:21 AM, Intuos5 said:

3. If you apply the text style that contains numbered lists to masterpage text frames and apply different masterpages to a left and right page document spread, the invisible frames from a masterpage do end up adding to the numbered list counting, even though there is no way to tell they do (from a user perspective). It doesn't seem to matter whether you have enabled or disabled the numbered list within the text frame.

Same with this one, we are already aware and is logged already.

On 9/27/2023 at 8:21 AM, Intuos5 said:

2. Numbered lists items take a while to recompute, so they appear to be buggy, whereas they in fact work as expected (after waiting a while and/ or triggering a page refresh by zooming).

I've just been able to replicate this and will get it logged