[Scribus] Registration marks

[Louis Desjardins]

>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