Proposal: V4 Feature: Master Pages

[dbolack-ab]

I have a few different ideas on ways we could shape this, but I think the first question is if this is seen as a thing of value to begin with...

For purposes of this discussion, a Master page is a single document page that contains content propagated to every page using it as a master page with the expectation every page of a document is using a master page.

[ericscheid]

Content? What kind of content?

I can imagine a conceptual master page which effects a style for the pages using that master, though such a thing could instead be done via CSS (using .page:has(.masterX) syntax, like we do with cover pages).

[dbolack-ab]

Any arbitrary content.

Honestly, we could (you could argue we already do) implement a very crude version of this simply with snippets, but there are patterns that doesn't support well which is largely what this discussion will be about.

[calculuschild]

Do you mean specifically style content or text content?

[dbolack-ab]

"brew frame" content. Style content, aside from {{}} and {} injections are outside of the scope here.

[calculuschild]

Can you specify the type of patterns you would want to see here that the snippets don't support well?

[dbolack-ab]

Can you specify the type of patterns you would want to see here that the snippets don't support well?

The most obvious? User creation and editing. The master page markdown being hidden from the brew edit window unless raised into it would be nice as it decreases clutter and might shrink brews somewhat. Master page assignment without user input ( default master page or use the last page on new page ).

[calculuschild]

Is there a particular use case in mind? An example of what kind of end result you would hope to see?

[dbolack-ab]

The main use case for master pages is when you have a page layout that contains a number of repeated elements. Header/Footer, specific column layout(s), fixed graphical elements, etc. that are tedious to duplicate from page to page accurately. The natural extension of that is when you have multiple spans of pages that each have their own common elements ( such as a Spells chapter using distinct footer from a Monsters chapter )

The idea of master pages, in my experience, includes the following concepts:

1. May contain any normal content for a document page
2. Understanding of "left" and "right" pages if appropriate
3. Immutability of master page content on document pages
4. Ability to "pull" the content of the master page into the active document page so that it can be edited. IME this works by cloning the master page content to the document page and then resetting that document page's master to the blank default
5. Any document page may use any master page.
6. New document pages inherit the last used master page
7. Setting frames for text pouring order
8. A separate master page editor flow for the master pages that follows the patterns of the document page editor other than being limited to a single page or spread as appropriate.

We can, functionally - if awkwardly, implement most of the non-programatic parts of the above with snippets, particularly if/when we get a document snippets concept (in support of brew templates.) The content portion of a master page is really no different than any brew page between the \pages.

The things we can't do now are all the programmatic features that move this into a labor saver and consistency enforcer.

[ericscheid]

Repeated elements can also be repeated via variables.

Though remembering to insert the variables into each page will remain a minor pain.

[dbolack-ab]

That's kinda the point. Yes, we can currently do about 90% of what a master page does to the page manually. The main idea is NOT having to do it manually.

[dbolack-ab]

In looking at 3258 (Sections) today it seemed a good idea to consider the idea being introduced there and how it does and doesn't interact with the idea of master pages.

The idea of Sections was to provide a method for setting multiple page numbering sets and corresponding labels to the manuscript. This can currently be done manually by the page number renumbering system and manually setting section labels. The current implementation allows for frontmatter ( everything up to the start of the book text ), chapter, appendix, and index sections, setting --HB-_Section_Label for index and appendix while clearing it for the others. It uses --HB_Page_Number_Style for setting the number expression style. It assumes every page is the same section as the last declared section ( no need to set every page ) while resetting the php-page-numbers on the first one. Lastly, it currently only allows for one of each section type.

Extension work is needed to track multiple entries in each category.

Master Pages can take care of setting the section label and numbering type and resetting the page counter if you assume that Master Page is only used for that section type and there's only one section of that type corresponding to that master page.

On reflection, I think that for the vast majority of users Master Pages provide coverage here. Should users feel a need for automatic indexing plural sections we should be easily able to extend the work.

[dbolack-ab]

I have added four PRs to build this out.
#3792 #3817 #3818 #3819

[dbolack-ab]

I've removed these to declutter the queue until they are more fully discussed.