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.
Return to the Linux DevCenter