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:
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:
<!-- some content displayed as a background master page -->
<masterPage rendering-order="under"/> <!-- optional -->
<masterPage rendering-order="over"/> <!-- optional -->
<page> content </page>
<page> content </page>
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,
-- 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
- 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
- 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_ 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.
 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.
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.
Inkscape. Draw Freely.