Louis Desjardins wrote: > 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.
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? -- Craig Ringer
