>Hi Louis, Hi Christoph,
[snip] >[...] Unfortunately, some (many!) printers expect imposition, crop >marks, registration marks etc. already to be provided by the layout >people. In most cases this makes no sense at all, since the printer >knows (or at least should know) the advantages and shortcomings of >his machines better than anybody else. This has nothing to do with >effiency, but only serves to blame someone else in case something >goes wrong. In the cases cited in my previous post, there is nothing wrong if the file has no registration marks. :) People should be confident the Scribus PDFs they handle to their printer is first-class material to work with. Testing first will eliminate at root the need for blaming anybody! :) >Many small shops I know use Quark/InDesign/Illustrator for >impositions. Thus, in the long run, the ability to do (at least) >impositions will become a necessary feature of scribus. AFAIK none of these products have imposition capabilities as such. Quark doesn't, for sure, unless you get specific XTensions [plug-ins]. However, any of these programs will allow to rotate any elements and position them very precisely within any single page. This is all part of imposition. From that perspective, Scribus can do the same. But can we say this is an imposition program? My answer is no. I mean, it's going to be ok for limited tasks, or for difficult tasks once in a while. A prepress house or dept. that has to fulfill the needs of offset presses on a daily basis will never be able to get away without a fully dedicated imposition application... or at the cost of time-consuming operations with tools that are not made for that. :) That said, I agree there is a need for small imposition tasks. I think Scribus already have a few good solutions working with scripts. People who need to print their own booklets on a digital printer, is a good example, I think, of why we'd want this feature within the application. As for the rest, we have had quite a few very interesting discussions on that specific issue over the last year or so on the list. I can't recall we ever came to a point where this is settled or whether we reached consensus! My own personnal view is towards a dedicated program. There are a few reasons for this : Imposition is critical in the printing process. In the workflow, imposition is very close to the presses. Imposition implies lots of details for any given press and any given project. It is very unlikely that a designer team will want to go over that fence and play in such technical ground. Plus, a design team may have a few printers to work with, all of them having their own press marks specifications and position. Will they keep an eye on all the possible layouts? Will they keep track of all the possibilities of, for instance, size, weight and grain of the paper, page gap, creeping, and so on? Mistakes on the horizon. Mistakes that can be at least time-consuming, at worse very costly. If we have to draw a responsibility line, here is a good spot. CTP systems and the automation of color adjustments, and all other controls, have made imposition an even more specialized task. The printer will most likely want to have total control on this part of the job. For instance, if for any reason a job has to be switched to another press (something totally out of control of the design team) imposition might have to be redone. Sometimes for tiny adjustments, sometimes for more. Last minute changes don't always occur on the document itself. What about a last minute quantity change or paper change (which in turn makes you realize that the new paper doesn't come in the same size)? These variables can substantially modify the printing scenario to the point where it will affect the imposition. Not to mention the post-press operations. In the end, imposition is a specialized task in the whole workflow. In my view, if we're going to step into this, it's going to be a very different project. Related, yes. But different. :) As long as Scribus can output reliable PDFs (which it does, imo), this leaves the ground open for anybody to write such a program. Cheers! Louis >Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050625/65b432c6/attachment.html
