Sometimes putting words to paper requires more than just a word processor. For designing and publishing newsletters, magazines, catalogs, and other printed pages that feature fonts (and graphics, photographs, or other images), a page layout application works best. Scribus is such a solution for Linux. While there are other desktop publishing (DTP) applications for Linux, based mostly on TeX and LaTex, Scribus sports a friendlier user interface and more features. In fact, it has evolved into a worthy competitor to the print industry's premier layout programs for the PC and Mac: PageMaker and QuarkXPress. Its development has also helped to advance the use of font typefaces and color management on Linux.
Notable features of Scribus version 1.2, released in August 2004, include:
For now, Scribus runs directly on Linux, HP-UX, Solaris, BSD, and Mac OS X (thanks to Fink), but an experimental port with KDE-Cygwin on Windows 2000 is in testing. Also for testing, Scribus has built on a 128-bit version of AIX. Scribus is available under the GNU General Public License.
"Quark was the model for the first versions of Scribus," acknowledges Franz Schmid, a 40-year-old invoice writer from Breitenfurt, Germany, who created Scribus. "I had a Mac and loved its desktop publishing applications. Soon after my first steps into Linux, I realized that there existed no user-friendly publishing package. So I decided to write my own."
Scribus undergoes rigorous real-world testing and use in professional mass-printing situations. Peter Linnell, one of its developers, works as a consultant specializing in prepress printing. "My most important client is a publisher," says the 40-year-old network consultant, who now lives in the United Kingdom. "They have been very supportive of my efforts with Scribus. Thus, I am able to test Scribus in a 'real' prepress environment."
The first version of Scribus used Python, with the Python bindings for Qt. Schmid says he chose Qt as the GUI toolkit because he felt it was the best one at the time (three years ago), with the most accurate documentation. As he added features, though, he concluded that Python had a few shortcomings. He switched to C++ to improve Scribus's speed.
"Looking back now, I still think that Python is a wonderful tool for quickly getting a mock-up running," Schmid says. "And translating Python code to C++ is very easy. When I ported Scribus to C++, there were huge chunks of code that needed only minor modifications."
Paul Johnson, a 33-year-old programmer from St. Helens, Merseyside, United Kingdom, who optimizes the Scribus code, feels that Scribus could have had better portability during its early stages of development. "Personally, I'd have gone for wxWidgets, as porting to other operating systems would have been less problematic," he opines.
The central technical challenge in developing Scribus has been bringing together the various libraries and code required to produce professional page layouts under Linux. "Scribus often pushes the capabilities of support libraries like freetype, Ghostscript, and even Qt," Linnell says. "Desktop publishing requires higher-quality output, whether we are referencing an image, font, or line drawing. What might be acceptable output in an office application could cost thousands [of dollars] if a press run is missed."
Fortunately for the Scribus team members, some of their most significant advancements came from the maturing of the outside libraries they incorporated into their own work. In desktop publishing, PostScript quality and reliability is critical, so improvements in the latest versions of Ghostscript show up in Scribus almost immediately. The evolution of littlecms over the years also had a noticeable positive effect on the program's color management.
"Littlecms has seen lots of real refinement," Linnell says. "Having a fully functional color-management system, which drops into Scribus, is a gift. Scribus is probably the best demonstration of littlecms's capabilities. We're encouraged to see the addition of littlecms to GIMP 2.0.x and have extended an invitation to other OSS applications like Inkscape to work with us on a common end-user setup and interface for any graphics application which wishes to add ICC color management."
Scribus can currently manipulate text in 25 languages. One might assume that this multilingual capability would have been difficult to implement, considering the multitude of fonts that the program must display and print correctly. Schmid says that creating the different versions of Scribus is very easy under Linux and especially Qt. Work is under way to support complex Indic scripts--a difficult task--and offer more complete CJK support.
"You only need a word/phrase list, which is translated into a small binary file. This binary file is loaded by the program at the start, and that's it," he explains. "Supporting this way of internationalization only needs three or four lines of code. The real work is done by the writers of these files."
For versions of Scribus beyond 1.2, the developers' first priority is to perform code cleanup and further optimization. Some features on their to-add list include support for the PDF 1.5 file format, more file import filters (Draw, Impression, OpenOffice.org), an improved user interface for font handling, and the ability for users to drop OpenOffice directly into Scribus.
Regarding the Windows and Mac OS X ports, Linnell estimates Version 1.2cvs running on Windows 2000 with KDE-Cygwin has 75 to 80 percent functionality. "What works, really works well and is quite stable," he says. "I think we will see 100 percent functionality in the next few months. We have had some invaluable assistance from the KDE-Cygwin team. We also have a native port to Win32 in the works, but the biggest challenge is developer time constraints."
"A [direct] Mac OS X port is possible--I've had it running, but it took about half a day to get the code to compile and link," Johnson says. Even so, he doesn't recommend that others attempt the method he used to accomplish this, which he describes as "hacks upon hacks." He adds, "This is why something like wxWidgets would have possibly been a better choice [for developing Scribus]. wxWidgets compiling under Win32 or Mac OS X is very straightforward."
When Linnell joined the development team, he recalls, "right away, I saw Scribus had lots of potential." He relates how far Scribus has come since then: "When I tell prepress folks about Scribus and its capabilities, thus far, they are stunned to find it is developed primarily for Linux."
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
Copyright © 2009 O'Reilly Media, Inc.