1:41 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
3:48 a.m.
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
9:22 a.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
Jon Phillips
San Francisco, CA
CHINA PH +86 1-360-282-8624
jon@...235...
http://www.rejon.org
MSN, AIM, Yahoo Chat, Skype: kidproto
Jabber Chat: rejon@...896...
IRC: rejon@...897...
Projects: http://rejon.org/projects
10:17 a.m.
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
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:24 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12:42 a.m.
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
10:22 a.m.
On Tue, Apr 1, 2008 at 3:42 AM, Donn <donn.ingle@...400...> wrote:
1. The canvas with the page is like it is now.
yes
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.
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.)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:29 a.m.
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
9 a.m.
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
11:54 a.m.
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
1:41 p.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:07 p.m.
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
2:15 p.m.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:34 p.m.
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
4:55 a.m.
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.
1:12 p.m.
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)
4:50 p.m.
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
8:21 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
8:38 p.m.
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
5:23 a.m.
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.
5707
days inactive
5723
days old
inkscape-devel@lists.inkscape.org
19 comments
9 participants
participants (9)
-
Bryce Harrington -
bulia byak -
Donn -
Jon A. Cruz -
Jon Phillips -
Josh Andler -
MenTaLguY -
Peter Moulder -
Tobias Jakobs