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.
On Mon, Mar 31, 2008 at 10:41 AM, bulia byak <buliabyak@...400...> wrote:
... 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. ...
In a lot of respects, page and pageSet containers are similar to groups or layers. Hence my proposal:
But even if you are doing it with groups, you don't solve the problem that it will no be viewable in other programs. At least not as different pages. Perhaps you could add a small javascript to switch the pages so that it would be possible to view the SVG is a browser. An other solution could be to have every page in a single SVG file and package the files somehow . (e.g. in a ZIP file)
Regards, Tobias
On Mon, 2008-03-31 at 12:48 +0200, Tobias Jakobs wrote:
On Mon, Mar 31, 2008 at 10:41 AM, bulia byak <buliabyak@...400...> wrote:
... 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. ...
In a lot of respects, page and pageSet containers are similar to groups or layers. Hence my proposal:
But even if you are doing it with groups, you don't solve the problem that it will no be viewable in other programs. At least not as different pages. Perhaps you could add a small javascript to switch the pages so that it would be possible to view the SVG is a browser. An other solution could be to have every page in a single SVG file and package the files somehow . (e.g. in a ZIP file)
Regards, Tobias
Wait, Bulia, why not use svg 1.2 multiPage?
http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html
Maybe my head is in the sand on this spec...
Jon
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Mar 31, 2008 at 12:22 PM, Jon Phillips <jon@...235...> wrote:
as I understand it's just an older draft of the same spec
On Mon, Mar 31, 2008 at 6:48 AM, Tobias Jakobs <tobias.jakobs@...1439...> wrote:
Perhaps you could add a small javascript to switch the pages so that it would be possible to view the SVG is a browser.
That's a good idea. We've just seen a good example of that with that SVG presentation script.
To everyone: Actually, it makes little difference whether we support <page> or <g inkscape:groupmode="page">. We can even support BOTH from the start. (The only thorn, as I explained, is the foreground master pages which per the spec force us to render things in order contrary to document order. But if we ignore that, everything else is easy.)
So, the question of what to write to SVG file is secondary. I'm more interested in your comments on the proposed UI.
On Monday, 31 March 2008 19:24:35 bulia byak wrote:
So, the question of what to write to SVG file is secondary. I'm more interested in your comments on the proposed UI.
I know you asked this of the OP, but multiple pages (if I grok the idea) would be very nice to have and I thought I'd cast a 'vote' for something similar to the old Freehand style of doing it, with tweaks:
1. The canvas with the page is like it is now. 2. There is a window with little pages (boxes with numbers) in it that can: a. Add/Remove a page. (buttons/keys or context menus) b. Click-clicking on a box shows that page on the canvas c. Dragging boxes changes page order. d. Enable/Disable a box (greys it) to include/exclude pages. e. What's drawn off-page stays on the screen while pages come and go. f. Selecting many boxes and 'grouping' them shows all those pages on the canvas (when selected). It also allows dragging of that group to re-order. Deleting too. g. Double-spread boxes, shown with a darker middle line, can be added or made by dropping a page onto another one (perhaps with a mod key to indicate left/right, or drop to left/right of target page box.) h. Each page gets it's own set of layers.
The way (I think I recall) that Freehand did it was to show all the pages on the canvas. The little boxes window was like a zoomed-out view. Dragging the little pages also 'dragged' the actual pages and they could be scattered higgeldy-piggeldy around the canvas. This could work too, but Inkscape has a limit to canvas size and that might cause problems - for example I was designing to-scale (in millimeters) and, at that size, one cannot zoom out much more than about 20meters by 20meters. After that it becomes purely a drag-canvas-around affair.
hth \d
On Tue, Apr 1, 2008 at 3:42 AM, Donn <donn.ingle@...400...> wrote:
- The canvas with the page is like it is now.
yes
- There is a window with little pages (boxes with numbers) in it that can:
a. Add/Remove a page. (buttons/keys or context menus) b. Click-clicking on a box shows that page on the canvas c. Dragging boxes changes page order. d. Enable/Disable a box (greys it) to include/exclude pages.
yes, all of that will be provided by pages-aware Layers dialog
e. What's drawn off-page stays on the screen while pages come and go.
no, that's a wrong approach - what if something is half on page and half off? :) Instead, you'll just be able to add layers before pages, or on a master page, which will show in the background of every subsequent page
f. Selecting many boxes and 'grouping' them shows all those pages on the canvas (when selected). It also allows dragging of that group to re-order. Deleting too.
we cannot yet do this for layers either, but it's not impossible to add such multiple selection to Layers dialog
g. Double-spread boxes, shown with a darker middle line, can be added or made by dropping a page onto another one (perhaps with a mod key to indicate left/right, or drop to left/right of target page box.)
that's hard, SVG Print has no provisions for double spread pages
h. Each page gets it's own set of layers.
of course.
So, with some discrepancies, what I propose is actually quite similar to the FH way of doing it. (By the way, from what I know, the lack of true multiple pages in Illustrator is one of the biggest problems for Freehand users trying to migrate to AI.)
On Tue, 1 Apr 2008 13:22:23 -0400, "bulia byak" <buliabyak@...400...> wrote:
f. Selecting many boxes and 'grouping' them shows all those pages on
the
canvas (when selected). It also allows dragging of that group to
re-order.
Deleting too.
we cannot yet do this for layers either, but it's not impossible to add such multiple selection to Layers dialog
I'd be leery of doing that. Right now "selection" in the layers dialog means simply "current layer". I think it would be confusing if it meant different things simultaneously.
g. Double-spread boxes, shown with a darker middle line, can be added
or made
by dropping a page onto another one (perhaps with a mod key to indicate left/right, or drop to left/right of target page box.)
that's hard, SVG Print has no provisions for double spread pages
I think we need to talk with the SVG folks about that actually; it's a rather significant omission.
-mental
bulia byak wrote:
Please let me know what you think.
I totally trust your judgment on implementation... The question I have though, is it really our concern if we were to implement per the spec (given if the spec doesn't change), and other applications can't handle this feature yet? If people want to use newer features, they should be aware of limitations of both inkscape as well as other software packages.
[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.
The only problem I see (which may not hold to be accurate), is that the last call for changes to the SVG-Print 1.2 module was Feb 8. http://svg.org/story/2007/12/21/20014/223
Chris, does that deadline still hold? Or was it extended without being picked up on svg.org?
-Josh
On Mon, 31 Mar 2008 04:41:08 -0400, "bulia byak" <buliabyak@...400...> wrote:
- Implement the same document structure, but instead of pageSet,
masterPage and page, use regular g elements with extension attributes indicating their role.
I think these should correspond to new values for inkscape:groupmode.
-- 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
I don't think that CSS visibility is the way to do this since it is global; we are probably going to want to have a per-view notion of "current page" just as we do for "current layer". (It seems to me that the one more or less entails the other)
Anyway, having something that maps to the SVG Print stuff is going to be necessary anyway, if we ever want to support SVG profiles. We'll need a way to preserve e.g. page information even in "downlevel" documents.
-mental
On Mon, Mar 31, 2008 at 2:54 PM, MenTaLguY <mental@...3...> wrote:
I don't think that CSS visibility is the way to do this since it is global; we are probably going to want to have a per-view notion of "current page" just as we do for "current layer".
But there's a difference: current layer does not affect what you see on the screen, but visibility does.
Besides, is it really useful to have two different pages viewed in two different windows with the same document? What will this buy you?
But apart from that, if we do decide to implement non-global visibility, how do we go about it? Show/hide arena items directly without touching SPObjects? This does not sound too elegant to me, although doable.
On Mon, 31 Mar 2008 16:41:14 -0400, "bulia byak" <buliabyak@...400...> wrote:
Besides, is it really useful to have two different pages viewed in two different windows with the same document? What will this buy you?
I could easily see myself cut and pasting elements between them, for example. Or just looking at them alongside one another for the sake of comparison (e.g. to make sure that the line weights or colors were consistent).
But apart from that, if we do decide to implement non-global visibility, how do we go about it? Show/hide arena items directly without touching SPObjects? This does not sound too elegant to me, although doable.
I think we'd probably need to set up some kind of framework for that rather than doing it on an ad-hoc basis.
-mental
On Mon, Mar 31, 2008 at 5:07 PM, MenTaLguY <mental@...3...> wrote:
I think we'd probably need to set up some kind of framework for that rather than doing it on an ad-hoc basis.
Sure, but how do you propose to go about it?
On Mon, 31 Mar 2008 17:15:40 -0400, "bulia byak" <buliabyak@...400...> wrote:
On Mon, Mar 31, 2008 at 5:07 PM, MenTaLguY <mental@...3...> wrote:
I think we'd probably need to set up some kind of framework for that rather than doing it on an ad-hoc basis.
Sure, but how do you propose to go about it?
I'm not really sure yet, I'm going to need to think about it.
Setting aside implementation considerations for a moment, I'd also like to start talking with the SVG WG about this, to see where we are with respect to finalization of SVG Print, for several different reasons. (One of the less obvious being that we may want to suggest changes to SVG Print based on our implementation experiences.)
-mental
On Mon, Mar 31, 2008 at 04:41:14PM -0400, bulia byak wrote:
On Mon, Mar 31, 2008 at 2:54 PM, MenTaLguY <mental@...3...> wrote:
I don't think that CSS visibility is the way to do this since it is global; we are probably going to want to have a per-view notion of "current page" just as we do for "current layer".
[...] if we do decide to implement non-global visibility, how do we go about it?
Consider the output format where we save as a zipfile of SVG documents.
If separate pages are completely separate SVG documents, then the implementation is trivial.
Supporting shared master stuff makes things harder. The problem is much the same as any other instance of embedding other documents in an SVG by filename reference rather than by content (and indeed that is the most likely SVG representation if using the zipfile approach), but it's more pressing to be able to refresh the imported document appearance in real-time (probably even before the master is actually saved).
pjrm.
On Mon, 2008-03-31 at 04:41 -0400, bulia byak wrote:
- 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.
This sounds like a fairly decent UI approach... and also could lend itself to two other main usage. Those are animation and icons.
Animation could map 'frame' to 'page', but we do need to keep in mind that animations can be time-based as much as they are frame-based. Frame-based is the easy case, but time-based is the more desirable case for the end users.
Icons can map versions to 'page'. So 16x16 4-bit would be one 'page' and 32x32 8-bit would be a second 'page' and 32x32 32-bit would be a third 'page'
I think the internals should be set up to support those three purposes in a common way, but then the externals might have some visible variation. So 'multipage' would appear noticeably different than 'icons mode' yet still would be consistent with each other.
Also... looking at the end-user work view as possibly different than the internals would allow us to adjust to changes in SVG print a little easier. We'd just need to account for changes in SVG print to impact the internals the same way that changes from multipage to multi-image icon does. (That is, abstract what might change in a common way, and split it apart from the aspects that will remain constant)
On Mon, Mar 31, 2008 at 04:41:08AM -0400, bulia byak wrote:
In a lot of respects, page and pageSet containers are similar to groups or layers.
[Ignoring underlying implementation details and focusing on UI as per earlier email...]
- 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:
It might be nice to have a way for the most common operations to be done entirely in-cavas rather than having to go to a dialog, so here's one rough idea...
A "document" is composed of sequence of pages with optional background and overlay. In the canvas this could look like:
+--+ +--+ |B1| |p1| +--+ +--+ +--+ |p2| +--+ +--+ |p3| +--+ +--+ +--+ +--+ |B2| |p4| |OL| +--+ +--+ +--+ +--+ |p5| +--+ .... : : ....
Or in Document Preferences the user can choose to have it run left to right (or whatever), so simply rotate the above diagram 90 degrees.
To add page 6, one would drag some elements from p5 down to the hidden area below p5, and the page is automatically added to the document.
(For adding a page inside a sequence, maybe allow right clicking in the space between pages?? Not sure.)
The last page in the document sequence can be automatically deleted by removing all elements on it.
Similarly, new backgrounds or overlays can be created by dragging some elements to the left or right of the document, and removed by dragging the elements off. [The areas to the left and right of the background and overlay pages are 'scratch' areas similar to the left and right of the page boundaries in single-page mode.]
To delete a page inside a sequence, or add a bunch of pages at once, or move pages, or other more complex things, use the dialog. (Maybe there are in-canvas ways of doing intuitive UI for these, but no ideas come to mind.)
It might be nice to enable the user to do X-by-Y multi-page drawings, by configuring in Document Preferences the # pages in both dimensions. For instance, a 3x2 drawing, with no overlay or background, and "no page spacing":
+--+--+--+ |p1|p2|p3| +--+--+--+ |p4|p5|p6| +--+--+--+
Obviously this also opens questions about crop marks, margins, and so forth. Could be complex, but for multi-page drawing could be extraordinarily useful.
The inverse of this is the "labels and business cards" scenario, where you have multiple documents printed on a single page. (I ran into this just recently when my fiancee and I tried printing seating cards in Open Office, and it frustrated us to tears. This seems like a use case well within Inkscape's potential. I mention it only because a sufficiently generalized multi-page document UI might be able to cover this use case as well.
Bryce
On Mon, Mar 31, 2008 at 7:50 PM, Bryce Harrington <bryce@...1798...> wrote:
A "document" is composed of sequence of pages with optional background and overlay. In the canvas this could look like:
Displaying multiple pages on canvas side by side may be doable, but it's hard with our current architecture and will be a major change in the traditional workflow. Just think of this: now, you can draw anywhere off the page and the new objects go to the current layer. Where will new objects go if you draw them off-page with multiple pages side by side? This will require quite a rewrite of the canvas code, at least. My approach - treating pages as special layers - is _a lot_ easier to implement, which is why I proposed it. Multiple pages on canvas may be worked on later if necessary, once we get the basic functionality in.
bulia byak wrote:
On Mon, Mar 31, 2008 at 7:50 PM, Bryce Harrington <bryce@...1798...> wrote:
A "document" is composed of sequence of pages with optional background and overlay. In the canvas this could look like:
Displaying multiple pages on canvas side by side may be doable, but it's hard with our current architecture and will be a major change in the traditional workflow. Just think of this: now, you can draw anywhere off the page and the new objects go to the current layer. Where will new objects go if you draw them off-page with multiple pages side by side? This will require quite a rewrite of the canvas code, at least. My approach - treating pages as special layers - is _a lot_ easier to implement, which is why I proposed it. Multiple pages on canvas may be worked on later if necessary, once we get the basic functionality in.
It's a great point about the off-canvas area, and I abuse the hell out of it on every document I create. To me it seems like having multiple views (which could potentially utilize viewboxes for display when we support them) would be a great way to handle it. One example of a view mode would be a per-page view which has the canvas and "bonus" area surrounding it visible. But, side-by-side view of pages (as well as a toggle-able view for single page viewing) would hide all off-canvas objects for visible pages. The around canvas stuff would still exist and be stored in the same way it currently is... it belongs on this layer, on this page. Either way, if implementing this in the per-page viewable at a time way is that much easier to implement, why don't we get the functionality in, and leave the ui for refinement when desired?
-Josh
On Mon, Mar 31, 2008 at 04:50:57PM -0700, Bryce Harrington wrote:
On Mon, Mar 31, 2008 at 04:41:08AM -0400, bulia byak wrote:
In a lot of respects, page and pageSet containers are similar to groups or layers.
[Ignoring underlying implementation details and focusing on UI as per earlier email...]
- 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:
It might be nice to have a way for the most common operations to be done entirely in-canvas rather than having to go to a dialog, so here's one rough idea...
Well, it is a rather special view: one would presumably still want to activate a menu item / button to switch to this multi-page view. Essentially, it is the same as a dialog box, bar some widget arrangement details.
Though I too tend to think that the interface shouldn't be so close to what we have for layers.
From an internal representation perspective, I believe we do want to maintain separate [logical] pages rather than having one big coordinate space, just so we can handle the off-page drawing element issue.
As you say, logical pages needn't be in a one-to-one relationship with physical pages. A spread or poster might be considered a single logical page, without considering the magazine/newspaper case where a single side of paper has two page numbers, or the book case where a single side of paper might be folded & cut into many many page numbers.
For some of these issues, we'd need to talk to Scribus people: these sort of page arrangement and editing issues are very important for many DTP users, and we might as well share the same interface. Accordingly, I won't comment on the suggestions for interface for page insertion/deletion, page to paper mapping etc.: such discussion belongs primarily in a Scribus forum, where the users have a lot of experience with these things, and where we'd presumably want to copy whatever is best for scribus for such tasks.
The inverse of this is the "labels and business cards" scenario, where you have multiple documents printed on a single page. (I ran into this just recently
For anyone else who runs into this, there's a command-line tool psnup ("postscript n-up") for this.
pjrm.
participants (9)
-
Bryce Harrington -
bulia byak -
Donn -
Jon A. Cruz -
Jon Phillips -
Josh Andler -
MenTaLguY -
Peter Moulder -
Tobias Jakobs