Master Pages
The concept of master pages exists in many software applications. It is basically a «template» (or multiple templates) that you can establish once and then use many times in your document. QuarkXPress and InDesign support it. Even in PowerPoint, this concept exists and is called «Slide Master». It usually gives you the ability to set up repeating elements that are then shown on every page. In QuarkXPress, InDesign, and PowerPoint, you can then also change these elements (in one way or another) on a per-page basis.
Scribus
Scribus made a radical – and simplistic – decision: If a page is based on a master page, all elements of the master page are shown, and you cannot overwrite any of these elements. It is more like a «background image» with the elements you defined on the master page.
Despite the fact that there had been many discussions in the Scribus Forum and Scribus Wiki in the past, and it had always been decided that this was the right decision for the moment, I wondered if I could write a plug-in to give the software the ability to change master page objects on a page level. I therefore did some research into how other software stored «overwrites» on a page level.
QuarkXPress handling
QuarkXPress has a very simple system: If you create a new page from a master page, all items from the master page are copied to the new page. Every item keeps a back reference to its original object on the master page (not yet confirmed by libqxp), and the page itself has a reference to the master page. If an element on the master page changes an attribute, all «linked» elements on the pages are updated with that attribute if it was not changed on the page and was therefore overwritten.
The implication of this is very interesting. Our master page could look like this:
Now, on a page, we could change any attribute of the object, and since we are working on a copy, there are no further implications.
Notice the changed text (an attribute) in the yellow box.
InDesign
InDesign has a quite different approach. We have the same master page:
What InDesign does is store a reference to that master page for each page (as QuarkXPress does), but it does not copy all the objects; it simply renders the objects from the master page on each page. I would say it is an «elegant» way to store just a reference. But now, if we change an attribute of an object on a page that originally sits on the master page, InDesign marks the original object at the page level for the renderer so that this particular element is no longer rendered on that page. It then creates a copy of the now-hidden original element on the page, and this new element has a reference to the master page element. In the IDML (InDesign's exchange format), it is easy to see: <Page AppliedMaster="ud6" OverrideList="u13a u171" … />. So, the page has an applied master (by ID), and the two IDs indicate that u13a should no longer be rendered on that page and that u171 was originally a copy of u13a. Interestingly, this new element (u171) is not rendered in the order of u13a, but belongs to the normal page, while the elements of the master are in the background:
Notice that the changed text box is now a new copy sitting on top of the elements of the master page. Interesting decision.
What is better?
InDesign's approach is very elegant. The file format stays small, and it sounds logical at first. But I have to say that the simplicity of the QuarkXPress approach is also great: There is no branching during page rendering, and there are rock-solid copies of everything. I am really not sure what I would implement when starting a new project. But for a project like Scribus, the QuarkXPress approach (a full copy of every item on the new page) is probably more feasible; the file format stays the same because the back reference to the original item can be stored in attributes that Scribus already offers. The plug-in would then need three hooks to change Scribus's functionality:
- On page creation based on a master page, create copies of the items of that master, including a back reference.
- If an item is changed on a master page, look up all copies in the document and update all attributes that have no overwrite at the page level.
- Do not render items from the master page anymore, because we have copies on every page.
The last point would also be very nice if Scribus supported that function natively, so that a page could have a link to a master page without rendering the items. That would be a Boolean value in the page attributes. With that, my plug-in would be fully compatible with a stock Scribus installation: no other person would need to install the plug-in but could still see the same document when opening it. Only if you want the convenience of changing the master page and having all copies update would you need the plug-in.