Imposition proposal

Imposition: a implementation proposal

This proposal is based on the notes about imposition in this wiki and a tech report (http://www.prepress.pps.com/TechReports/imposetr.html) by prePress (http://pps.com)

This document has been written in order to facilitate the discussion on the implementation of the imposition for Scribus. If you're not clear what implementation is, please do first read some documentation about it.

At the time of writing (15th March 2006) all points are still under discussion.

The goal of the project

The target user of the imposition in (or for) Scribus is the private user which:

• wants to print a booklet on his home printer;
• has to prepare a job to be sent to a professional printer.

The imposition tool is not meant to replace high end tools used by professional printers.

The features set

There are many features which could (and or should) be implemented for supporting imposition. This section wants to be a comprehensive list of all features which could be implemented:

• it won't be comprehensive,
• not all features will be implemented.

Multiple pages

The basic idea of imposition is to put multiple pages on one printed sheet.

The user should be able to define how many rows and columns of pages he wants to compose on the paper.

It also should be possible to print a sheet full of the same page (like business card)

The size of the target page

The user should be able to define the size of paper which will be fed to printer.

The default value is the size of the source page multiplicated by the number of pages on the sheet

Example: if you want to print a normal booklet from an A4 document, the default is to create a A3 page.

Resizing the source pages

The default is to use the original size from the source document.

If the size of the pages has not been set, modifying the size of the target page will automatically adjust the size used for the source pages to fit the whole resulting page.

Also resizing not proportional.

Margins

The user should be able to define a margin for the sheet and around each page.

The default is to add no margin at all (The margins defined in the source document are used for every page imposed!)

Example: When downscaling a document it could be necessary to correct the margin to enforce the minimal margins defined for the printer.
Example: A booklet can be layouted with a zero margin, printed with a 1cm margin around the pages and then cut to be without margins.

Creep -- a special form of margin between the pages -- could be implemented as an automatic (based on the thickness of the paper) and a manual option. It could also be necessary to slight rotate the page.

Ordering the pages

Basically the choice is between:

• normal order
• booklet order
• custom order

The user should be able to define a signature. There should be a default signature which is used if the number of pages is above a given number (32 pages?) to avoid too hard useless calculations.

If the numbers of pages in the document doesn't match the choosen signature, a filling page (or empty) can be choosen.

Given the complexity of the ordering process, the user should be shown a [view] of the layout.

If a folding option is choosen, it should be possible to get / define a rotation of the pages on the back side, in order to achieve matching pages.

It should be possible to manually define the order of the pages, as an example to enable a clever printing of mixed colors jobs ((spot) colors only on selected pages).

Duplex handling

Completing what already has been written in other sections, duplex printing can require two extra features:

• Enabling printing in two shots (first the even sheets, then the uneven ones).
• The way the paper is turned affects how the pages are mirrored while "automatically" ordering the pages on the printed sheets.

Graphical and text elements

Professional printers can require some graphical or textual elements on the page like:

• cut cropping marks,
• color bars,
• registration marks,
• comments, page number.

Some of these can be but on arbitrary / fix positions, others like the page numbers have to be placed by the user when composing the printing sheet.

The dialog

There are two ways of implementing an imposition dialog:

• integrating it in the print dialog,
• launching an imposition dialog from the print dialog

Even if not all the features proposed will be implemented it is to expect that several tabs will be necessary.

The choices in the dialog should be as graphical as possible, the values should be choosed in drop down lists and there should be as few text fields as possible.

Implementation

Types of implementation

There are four possible ways of implementing the imposition for scribus.

External tools

There are some external tools which can be used to make imposition. For postscript files, the choice would probably be "ps2ps". For pdf there is multivalent but it's not free.

The postcript tools are mature, not the pdf ones.

An alternative would be to implement a new pdf tool which would have a similar interface as ps2ps, using the scribus pdf handling code and use it for the imposition in scribus.

Scribus code

Just add the imposition class in the scribus code.

It's probably the easiest way, but not the "cleanest" one.

One big question is, if the actual pdf and ps scribus code can be easily used to stear the imposition.

Scribus plugin

If Scribus can launch a plugin from a dialog and get back to the dialog after quitting the plugin (it seems it works for the print preview plugin) it could work.

It feels somehow natural to implement the imposition as a plugin.

A downside is (probably) that the rest of the scribus code (pdf handling) can't be directly integrated in the plugin (or yes?).

Special Scribus pages

It has been proposed to implement the imposition through special scribus pages which would contain document frames.

It's probably the best way to easily implement several of the most advanced features. On the other side, it could be hard to simply create a booklet.

The complex dialogs needed for stearing the imposition could be avoided and the simpliest cases (like a simple a4 booklet printing) could be provided through a template system.

This pages could describe how the pages (already "exported" as pdf or eps) are placed.

The GUI dialog could create the file (checkbox). It could be a possibility to create a Scribus file which could be tweaked by the user (even with a script).

Handling the virtual pages

Working with Pdf

Pdf-in-pdf would be ideal, then Scribus could impositions documents from other sources. But I think a solution could support both importing pages from pdf and importing pages from sla?

Maybe we could even start with having a solution importing PDF pages as pictures (as it is done today) and then just improve it by adding other import formats?

Order of the virutal pages

Trough a .sla document

Create a document with a certain paper size (can even be done manually?). Here we should probably also include tumble or turn (to place the two pages of a sheet next to eachother or above/below eachother on the workspace)

Insert guides according to printer margins and page grid (easy to script, 4 margins and number of rows and columns)

Create frames according to the guides (easy to script too, maybe the same script as above, it will really not create them using guides but use the same numbers as for drawing the guides)

Then the user must select a page order and rotation for each frame. This I think must be coded into Scribus. Each frame must have some visible identifier showing it's orientation and sequence number

Maybe also alignment of page within the frame should be available (if the page is smaller than a grid square). I don't have Scribus in front of me now so I'm not sure if alignment of image within an image frame is arelady available

Then importing pages and duplicating the setup for additional sheets can be easily scripted (possibly with an option on how many pages on each signature)

Trough a dialog

Through a Dialog with some images with (rotated) numbers on them

Starting the implementation

• a dialog creating a .sla file
• the user can tweak it if he wants to
• using pdf (first rasterized then real pdf ) or ps frames
• it will be a plugin

Input still to be classified

Louis

I have to insist on the fact that if we are going to put energy and coding time on an imposition solution, the first goal IMO should be for users printing on small digital printers. This is what we read the most on this mailing list. Booklets being the most asked feature. This is very reasonable and is what lots of people would expect from a solution like Scribus.

Graig Ringer

I couldn't agree more, and it's for this reason that I increasingly think imposition might be best done natively as part of the PDF output process. By separating physical pages from logical document pages and using a logical->physical mapping for PDF output it wouldn't be too hard I think. Users could then be presented with a series of pre-set mapping styles and the ability to enter their own. The mapping would include page order, rotation, scaling and positioning.

Since the mappings themselves would just be an abstract data structure they could be saved to an XML representation for re-use, and for use in non-GUI PDF output.

Imposing pages from 3rd party PDFs would be accomplished through pdf-in-pdf embedding support (not yet available, but EVERYBODY wants to do it when it's practical), by placing them on a page. Because of that the imposition support would not need to worry about PDF input directly.

I suspect doing things this way would be the most maintainable, easiest for the user to get right, and generally most useful. Thoughts?

What things would you expect the mapping to need to do/contain?

Gregory Pittman

we might translate this into considering what kinds of Scribus operations would be helpful for these tasks, and perhaps other similar but not identical tasks that a user might desire.

The first is the ability to take a Scribus page as a whole and resize it, plus other operations like rotating or making a mirror image (I'm trying to think generically). So one could easily convert an A4 page to US Letter, or take two pages the size of an A4 and shrink/rotate to make an A5 booklet page.

The second is in regard to imposition as well as more generalized operations that involve rearranging the pages in an organized fashion. This might not necessarily happen at the .sla document level, but rather as the document is being exported to PDF. Perhaps a post-processing after PDF export.