This topic has been discussed a lot... but now I need this feature for a project, so I decided to look in detail into what we can do to enable multiple pages in Inkscape.
There is an SVG Print specification from W3C which deals, among other things, with multipage SVGs:
http://www.w3.org/TR/SVGPrint/
However, it is still a draft. I don't know when it will become a final spec. We have already been bitten once by jumping the gun and implementing a thing which was later dropped from the standard and replaced by a quite different one (flowtext). Besides, even when it is final, it may take years for SVG software to catch up to it. And I'm sure a lot of software will choose to ignore SVG Print because printing is simply not on their agenda.
All of this makes me very reluctant to go on with implementing the current SVG Print multipage model. If we do, we may end up with our multipage documents unreadable by most SVG software out there, even though we will follow an official spec.
Yet, let's look and what SVG Print proposes. A multipage document looks like this:
<svg> <!-- some content displayed as a background master page --> <pageSet> <masterPage rendering-order="under"/> <!-- optional --> <masterPage rendering-order="over"/> <!-- optional --> <page> content </page> <page> content </page> ... </pageSet> </svg>
In a lot of respects, page and pageSet containers are similar to groups or layers. Hence my proposal:
- Implement the same document structure, but instead of pageSet, masterPage and page, use regular g elements with extension attributes indicating their role.
- Reuse the Layers dialog for displaying and switching these page containers as well, making them part of the overall layers tree displayed in that dialog. In this way, each page may have its own subtree of layers, but there may be shared layers that show up on all pages, stored in master pages or in the content before the pageSet (which is also treated as a background master page). Of course the Layers dialog will have to treat such page-layers in a special way, namely:
-- display them differently (font, color, autonumbering)
-- enforce that only one of the sibling pages is visible at a time: as soon as the user switches to a page and makes it visible (perhaps for pages, we can implement "clicking on name makes visible"), all other pages are hidden, using the standard CSS visibility property as is done for layers
-- when a page gets visible, its nearest preceding masterpage also gets visible, all previous masterpages get hidden (as per the SVG Print spec)
- In addition to Layers dialog, we'll also need a small page flipper in the statusbar, next to the quick layer selector, hidden for non-multipage documents; the quick layer selector should perhaps be limited to the layers of the current page and the currently active masterpage only.
- Add commands like New page, Duplicate page, Delete page, etc.
I think this plan has several important advantages:
1) it gives the required functionality without too much disrupting the existing workflow; in particular it makes obvious the relationship between layers and pages, which otherwise may be confusing;
2) it is relatively easy to implement with the existing infrastructure;
3) it lets any SVG 1.1 software to view Inkscape multipage files, if only the page which was last viewed in Inkscape before saving;
4) it maps _almost_[1] one-to-one to SVG Print and will be easy to switch to using the dedicated SVG Print elements at any time.
Please let me know what you think.
[1] Why "almost"? There's one small detail in SVG Print which cannot be emulated in SVG 1.1: a masterPage with rendering-order="over" (foreground master page) must be rendered on top of the current page, but it comes _before_ it in document order. I find this very unfortunate and I actually think it might be a good idea to suggest changing this before the spec is finalized. Namely, replace
The Background Master Page and Foreground Master Page MUST be the ones most closely preceding the page in document order.
by
The Background Master Page MUST be the one most closely preceding the page in document order; the Foreground Master Page MUST be the one most closely following the page in document order.
With that change, a 100% emulation of this with SVG 1.1 groups will be possible (unless I'm missing something, of course). Unfortunately, this change will likely be rejected because, from what I see, one of the motivations in SVG Print is to make a document "streaming" so that a page can be fully rendered without looking forward in the document. If that is the case, then I guess we'll just need to drop support for foreground master pages in our implementation.