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 graphical 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

Algorithms

Booklet printing

Dean has proposed the following algorithm for booklet printing:

The positioning of pages for “booklet printing”. Also known as “printers-pair” differs from the sequential form of “readers-pair”

8pages

Readers-pairs.	1-2, 3-4, 5-6, 7-8
Printers-pairs.	8-1, 2-7, 6-3, 4-5

Formula for calculating Printers-pair

known data at start.

Total-Pages of Document	Tp	Must be devisable by 4
1st page of document	P1	Always 1 sits on rh-side of back page
even pages on left side of pair
odd pages on right side of pair
sum of pair is equal to Total-Pages plus 1

Tp=8
Chk=Tp+1	Chk is value to check validity of pair.
PP1o	printers-pair 1 odd is on the right of pair1 (Tp is left-hand component)
PP1e	is equal to Tp
PP2o	printers-pair 2 odd =Chk-PP2e
PP2e	printers-pair 2 even=PP1o+1
PP3o	printers-pair 3 odd=Chk-PP3e
PP3e	printers-pair 3 even=PP2o-1
PP4o	printers-pair 4 odd=Chk-PP4e
PP4e	printers-pair 4 even=PP3o+1
PP5o	printers-pair 5 odd=Chk-PP5e
PP5e	printers-pair 5 even=PP4o+1
PP6o	printers-pair 6 odd=Chk-PP6e
PP6e	printers-pair 6 even=PP5o+1

Input total pages of publication

Create Chk
Create printers-pair1e
Create printers-pair1o
Create printers-pair2e
Create printers-pair2o
Till end of document.

Note even pages are created first as even value is used to calculate odd value Ppno=CHK-PPne

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

The best ideas to implement the imposition seem to be:

• create pictures frames and import bitmapped pdf... and waiting (and hoping) to be able to import vector pdf in the future. not very difficult to implement, but not a good solution as long as pdf can only be imported as bitmaps.
• create a copy of the whole document, grow the page size to final size wished and move the frames in every page to a new place in fewer pages. there are some tricky parts (layers, master pages, maybe styles), but could be doable.

Not so good ideas seem to be:

• Importing pages from the main document: text flow gets broken.
• Use sla-frames (frames to import scribus pages): they're not implemented yet and text flows could also be problematic.

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.

Craig 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.