[Scribus] Outside question

Peter Linnell scribusdocs
Fri Sep 12 07:00:42 CEST 2003


Hi Patrick,

I am going to reply at first to this on the list, as I think some of the
other readers on the might find this useful. I wanted to think on this a
bit before responding. 

On Tue, 2003-09-09 at 11:27, Patrick wrote: 
> Hi List,
> 
> I am in conversation with a gentleman that just compiled Scribus for his
> Sparc.  As you might have guessed, I do push Scribus to others, even
> on a possible competitors mail list.  He is a past Amiga PageStream
> user as I and was anxiously awaiting it's return, but now to Linux.  Not
> sure if it will happen and not sure it will be worth purchasing, when
> Scribus is here already doing a great job!  I am on that mail list as
> well, watching it's progress to see if there is actually a working
> version in this decade.  ;o)
> 
> Anyway, Jack had a question about Scribus and it's "commercial"
> abilities, so I thought I would pass along his questions.  You can
> respond directly to him or me or the list with your comments as I will
> pass them along.  I suggested he join the list as well.

Yes, I would recommend he join the list as well. The exchange of ideas
would be helpful. With friendly developers <g>, supportive users and
folks like me who are in the pre-press world, we could use a couple of
knowledgeable printers. 


For whatever issues Scribus may or may not have - at least it is not the
DTP pretender from a north west state in the US. ;)

> Here is the quote:
> 
> Yes I did compile it over the weekend, it seams to be nice, but what
> about spot color, PMS matching, I can see it would work ok for 4 color
> sep, and I understand it does 4 color CMYK on the fly if you have 
> RGB graphics, I haven't used it too much but it looks good. I know
> Pagestream has these features and more.

First, I would have him look here:
http://www.atlantictechsolutions.com/scribusdocs/pre-press.html

The PDF is a listing of my testing of Scribus 1.0+ files to date with
other well known DTP applications. The missing part is the testing I
have done so far with a EFI rip which is designed for composite PDF. It
also does in RIP seps of PDF etc. The good part is -  so far so good
with good fonts and images. 

I get predictable screen to print matches on RH 9, Scribus 1.x with
littlecms 1.10 and 1.11 beta using monitor profiles generated with the
lcms profiler and via Monaco's color tools and a spyder under Win2k.
(This is a dual boot machine.)  I have compared the profiles generated
by the littlecms profiler and they are fairly close. The printer
profiles are generated with Monaco's pro tools, as well as the canned
profiles included by EFI. 

Usable color management is a major leap for any open source app. That is
not trivial.  I might add there is more than can be done with the color
management stuff. The newest lcms 1.10 and 1.11 have a lot of work done
for optimizing color managed printing including new bits for controlling
ink limits, black point compensation and other subtle tricks. Hence, HP
has sponsored littlecms in their last couple of releases. It says a lot
when the largest printer company in the world sponsors your open source
project. 

BTW, the GIMP developers have added some very basic CMYK support in the
current 1.3.1x versions which will become GIMP2. It is not fully color
managed like Scribus or Photoshop, but it is a welcome start. Thanks in
part to Alistair Robinson who showed them the way with his separation
module, the GIMP developers have added some CMYK support. 

Crop marks - I have discussed this with Franz and sent some sample
postscript code, but this is where someone like your colleague can help.
They could be added, but we do not have all the correct specs for these.
Adding them is mostly some postscript code added around the page boxes.
I have looked high and low on the net for these specs. No luck yet. 

Registration marks/color calibration bars: same as above.

Spot colors can be imported via EPS and Scribus will pickup the spot
color name and use CMYK equivalents. I have imported Pantone spot colors
via EPS and they do show up in the palette with the correct Pantone
name. I not yet tested this with PS output, but will soon to a printer
with Pantone matching built in.  

As for PMS (Pantone Matching System TM), this is a proprietary color
system which needs to be licensed from Pantone. Whether they would be
willing to license their libraries to an open source project, I do not
know. The plus would be for them to have a broader audience for Pantone
spot matching etc. If they say yes, that would be interesting...


> Another issue I have is designing graphics as I would in Adobe
> Illustrator, there are a few that look fair but no PMS spot colors,
> trapping, crop marks etc. these are essential for commercial work as,
> inposition is also a feature missing from most DTP Layout Aps. This is
> very important when you run a Large 4 Color Press and need
> To output film for those large metal plates.

Trapping - setting the colors so they register properly when laying down
the inks on top of each other and imposition - laying out pages on
signatures are separate issues. None of my publishing clients do their
own trapping as far as I know. 

Quark Xpress and Pagemaker do have have trapping functions. However,
properly using this takes a fair bit of knowledge of the printing
process - more than I have observed with the typical designer using DTP
apps. From the perspective of a print client, I *want* the printer
handling this.

No DTP app does more than basic imposition as far as I know and this
typically handled by very specialized software *and* expensive software
like Preps. 

I do not think it would be too difficult to create the same basic
functionality to create simple imposition layouts like booklets and
calendars via the scripting plug-in. Imposition for this scenario is
mostly a matter of rearranging pages so they can be cut on a sheet fed
printer or in the case of a booklet laying more than one document page
on a printed page. 

I think it is really important also to know I have a lot of respect for
Franz's know how of postscript and printing - he is far more
knowledgeable than he might let on.. 

Given its relative newness, it is to be expected there are few bits and
pieces missing, but I think there is a wish and willingness to add these
as needed. 

One thing that is important to say if it is not obvious is Franz has put
a lot of effort into optimizing PDF output of Scribus. When Franz
started Scribus I knew this was a good idea, but I did not know then how
*really* good it was.  Having a solid PDF exporter has allowed Scribus
to overcome most all of of potential issues with Linux and open source
apps in the DTP world.

I have done some test PDF's of some of my client's magazine content
using the same files used in Indesign and Pagemaker to create PDF and
the printed results are so close you cannot tell by the naked eye which
app exported the PDF. These files include complex EPS files of maps with
something like 50,000 segments and large hi-res tiffs. I can regularly
make Quark blow up with this file....

>From an end user and printer client perspective this is a Good Thing TM.
It is impressive to see what a PDF oriented work flow can do when: 
a. You have a client that can generate consistent high quality ready to
RIP PDF. (That's what I get paid for!)
b. The printer has the latest Prinergy or Harlequin gear which handles
the.

I know PDF is not the solution for everything in the print world - but
it is a big step forward. The bottom line: one of my clients, where I do
lots of testing with Scribus, saved tens of thousands of dollars on
their print bill, the print quality has gone way up and their magazine
has been delivered ahead of schedule every issue. 

Given its rapid growth, it is not hard for me to imagine as Scribus
matures, when one could use Scribus as the main production app for this
magazine. Already, I am replicating content for test printing and really
do not expect any issues with Scribus files in the work flow.

The best part of Scribus is Franz has *always* delivered more than any
of us expected. 

That we are even discussing "commercial" usage of Scribus, as an open
source Linux based DTP app is the best evidence of his progress.

Just my thoughts, per Dennis Miller (smart, cynical American comedian):

I could be wrong, but that is one man's opinion.

Peter










More information about the scribus mailing list