Scribus: Open Source Desktop Publishing
Pages: 1, 2
The Developers Speak
Franz Schmid is the creator of Scribus. Peter Linnell is its documentation maintainer and, unofficially, the project's "abusive tester". He says, "With every stable release, I do my best to break it." Paul Johnson's role in the Scribus team is fixing bugs in the program and optimizing its code.
What advice might you have for others who are developing an application that uses fonts a lot?
Paul Johnson: Make the user interface as simple and friendly as possible. Try a number of ways before deciding on one. If possible, see how the handling is performed on different applications and operating systems--it really does make a difference when it comes to how users perceive the final product.
Peter Linnell: Get to know Fontconfig, as it is the future for font handling in Xfree86, if Linux is your target.
How would you compare Scribus to the industry standards in desktop publishing, QuarkXPress and PageMaker? For example, what major features does Scribus lack for now, but what features does it have which Quark and PageMaker do not? Do you plan to make Scribus "professional ready" someday--so that it can be used for magazine layout work, for example?
PJ: Scribus knocks the bells out of Quark and PageMaker already. I use QuarkXPress at work, and it really is unfriendly and counterintuitive. It is also slow. You can [run] Scribus on a Pentium 500MHz (system) and it performs as well as Quark 5 does now.
PL: Right now, Scribus is "professional ready" now. I have tested Scribus PDF files in a high-volume, four-color magazine, as well as written documentation specific for commercial printers to assist them with handling Scribus PDF and EPS files. We know have many examples of Scribus being used in a variety of projects. One of the Scribus users produced his 150-plus page high school yearbook with Scribus, including importing many advertisements created in other DTP applications. I actually got the final PDF files and ran them through a variety of prepress preflight tools. It just workedTM. Scribus PDF and EPS files, though they use many advanced features of the specs, are very highly conformant to the published specifications.
A weekly newspaper in the U.S., the Twin Tier Times, has developed a complete production workflow using Scribus 1.2 CVS versions, GIMP 2.0.x, and other OSS applications. The biggest challenge has been the printer; not having newer versions of prepress tools, they were initially unable to handle Scribus PDFs directly. But both Craig Bradney and I were able to work with the newspaper folks to come up with workarounds, well as providing some critical bug fixes for the immediate time being. It was close, but they met their first print deadline on time. When a company is willing to stake its success on an OSS application like Scribus, especially one based on the development versions, that the best indicator of Scribus's progress.
I told Franz [that] Scribus would ultimately be judged on the quality of PostScript and PDF output. In my testing, Scribus's PDF output is more reliable and robust than [that of] some big-name commercial applications.
Scribus has some firsts.
[It's the] first DTP application to support direct-to-PDF/X-3. Only the newest Acrobat 6 can do the same, and you still need to create the files in another application. While others can support a subset of interactive PDF features, only Scribus makes it so elegant from a designer's viewpoint. Scribus supports almost every interactive PDF feature in PDF 1.3 and 1.4. Other [applications currently] need support and more reworking in Acrobat to achieve the same result.
Scribus is also the first DTP application to have XML as the base file format. Short of a disk failure, I usually can reconstruct the most mangled file with a text editor. DTP files internally are rather complex. Every other DTP [application] has file corruption issues. This make saving files across a network really tricky. Scribus saves files to a Samba server without complaint. I have not lost a single Scribus document due to crash or corruption in more than a year. Mind you, that is almost always using the daily CVS builds.
QuarkXPress has been successful because the printing industry collectively understands its capabilities and has workarounds for its quirks. There are many things I do not like in QuarkXPress: I find it does not handle PDF or TIFFs well. The printing world is moving to all-PDF workflows. In my experience, QuarkXPress does not work well in this environment. PageMaker, as old as it is, is actually better equipped to go to all-PDF. [Using] PDF results in quicker turnaround, more consistent output, and reduced costs. InDesign has progressed remarkably, but really given the resources Adobe has at its disposal, it should [be] no less than stellar.
PageMaker's code base is quite old and is showing its age on newer platforms. It has problems with file corruption at times. While it creates reliable PostScript, exporting PDF is tricky. There are lots of things users can enable in a file, which cause errors down the line. Creating good PDFs is not simple and is fraught with errors for inexperienced users. Still, it is the most user friendly of the commercial apps. Once you understand how to avoid its pitfalls, it is serviceable.
I find Scribus to be very user friendly without handcuffing experienced users. Consider that Scribus has Python as a scripting language. [Commercial] DTP apps have scripting support, but it is not easy to implement and it does not travel easily across platforms.
From a pure productivity view, I find I can create certain types of docs faster and easier with Scribus than with the commercial apps. I have access to all of them. I have created training manuals for PageMaker and Acrobat using Scribus. It was easier. What I find interesting is to see how much users have done with Scribus already. I have seen newsletters which were commercially printed, and they are really well done [with] four-color printing, lots of pictures, columned layouts--what you would do in PageMaker or InDesign.
What contributions could you use from those willing to volunteer in Scribus' development?
PL: Anyone willing to do translations of the documentation. Already, there is someone starting on the German and French version. We hope to have the documentation in several more languages. We have a great community now online on IRC, as well as our mailing list, which is active and very, very friendly to novices and experts alike. We have a few commercial printers who are active in bug hunting, testing, and providing the kind of guidance to end users which has been fabulous.
PJ: Peter is doing an absolutely fantastic job on the documentation, but we could probably do with some more documentation in the code. It's good that Franz and myself are able to understand it--we've been working on [the code] that long--but for someone just coming to the [project], it may seem daunting.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the Linux DevCenter
Showing messages 1 through 10 of 10.
-
A false picture
2004-09-04 01:45:41 iconara [Reply | View]
In which world do you live?
In the world I live, GIMP does not support CMYK, so I find it hard to belive that anyone serious would create a DTP workflow using it, unless they handled only black-and-white-photos. Moreover, in the world I live and work, PageMaker was more or less decommissioned a few years ago (and now lives on as a plug-in to InDesign), which makes the comparison between PageMaker and Scribe quite pointless. InDesign is mentioned perhaps twice, which also does not reflect the world that I live in, where people started abandoning the sinking ship named Quark somewhere around InDesign 2.0.
So, to be able to take this article seriously I would have liked to see comparisons to Quark XPress 6 and InDesign CS, not PageMaker. But I guess this article was written by a tech-journalist for programmers, and not DTP-people.
Face it, Scribe is not going to dent the sales of InDesign or Quark one bit. GIMP is a laugh in the DTP-world. It's not that I'm happy with this. Oh no, it's nice to see that OSS applications like Scribe are being made, but they can't compete on this market, not just yet, perhaps never. -
A false picture
2004-09-05 04:43:22 rjplus [Reply | View]
Gimp does support CMYK at least for export and editing through a plugin, I use it all the time.
Importing of CMYK is not currently available but I usually create my graphics is Gimp so this hasn't been much of a handicap for me. Yes, I admit the editing is a bit of a hack but it works well enough.
see http://www.blackfiveservices.co.uk/separate.shtml
RJP
-
A false picture
2004-09-05 03:54:32 scribusdocs [Reply | View]
Well, now we have confirmation of two other weekly papers, besides the one in the article which are using Scribus and no, not black and white, but full CMYK color.
Scribus has its own RGB > CMYK conversion routines, including ICC support via littlecms, so whether GIMP has CMYK support is irrelevant. Scribus handles that part..quite well I might add.
Mind you this interview was conducted over different times starting a year ago.
So, to be able to take this article seriously I would have liked to see comparisons to Quark XPress 6 and InDesign CS, not PageMaker. But I guess this article was written by a tech-journalist for programmers, and not DTP-people.
You are invited to look at:
http://docs.scribus.net/index.php?lang=en&sm=printing&page=prepress
This will give you an idea of Scribus's pre-press capabilities.
What I did say about Pagemaker and Quark are still relevant. There are many many shops still on MacOS 9 and Quark 4.
Moreover, we could care less about Quark or Adobe sales, Scribus is all about providing similar capabilities for Linux users. The point of newspapers using this for production merely highlights Scribus's maturity and capabilities.
-
A false picture
2004-09-04 10:39:52 RobM [Reply | View]
GIMP 2 does support CMYK. -
Still a false picture
2004-09-05 05:27:39 iconara [Reply | View]
From the GIMP user manual:
Let us say first that Gimp doesn't support the CMYK mode. (An experimental plugin providing rudimentary CMYK support can be found at www.blackfiveservices.co.uk/separate.shtml.)
In the world I live, experimental does not mean "fit for production".
(http://docs.gimp.org/en/index.html)
-
Congratulations to the Scribus team
2004-09-03 19:29:40 Frank_Daley [Reply | View]
This article was inspiring. Congratulations to the Scribus team.
While it makes many of us cringe, a native W32 will be yet another great tool to assist spread OSS usage, most especially amongst schools and the SME market. I'm looking forward to having such a port that I can promote amongst my clientele in those markets.
-
PDF/X-3 claim is wrong
2004-09-03 14:25:12 dkelly [Reply | View]
Indesign has supported PDF/X-3 for a while and Apago's PDF/X Checkup plugin for Acrobat shipped over 2 years ago. PDF/X-1a is widely used in the United States. PDF/X-3 isn't. -
PDF/X-3 claim is wrong
2004-09-05 03:42:42 scribusdocs [Reply | View]
No, it is true
To clarify:
Indesign 2.x does not support direct to PDF/X-3. ID CS does.
Scribus has had this since 0.9.5 - 02 Jan. 2003
See: http://web2.altmuehlnet.de/fschmid/ChangeLog
At that time, neither Acrobat 6, nor ID CS were released. So yes, Scribus was the first DTP/layout app to support PDF/X-3
Although the article may have been a bit biased as it quoted the developers of the package, I find it amazing that I can download Scribus and use if for free.
Don't you?