[Scribus] Registration marks
Sat Jun 25 14:51:27 CEST 2005
>[...] 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus