Scribus: Open Source Desktop Publishing

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:

A robust, commercial-grade PDF export engine with capabilities exceeded only
by Adobe's own Acrobat 6.0 Professional.

A new high-performance, anti-aliased, WYSIWYG rendering engine for
displaying the page canvas.

An integrated story editor, which handles the application and editing of
styles, with extensive Unicode support. Indic and Asian scripts are in
progress.

Excellent support for EPS, PS, and SVG import and export, allowing the editing
of all imports as native Scribus objects.

Exporting of CMYK separations and "press ready" PDF files, including PDF
1.4 features such as transparency and gradients.

Cross-platform Python scripting for extending functions and automating
tasks in the program, and accessing external applications from within it. The
Python scripter can control many facets of Scribus, including a font sampler
script that demonstrates its capabilities.

A fully documented, XML-based native file format.

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."

Higher-Quality Text Output

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."

More File Support and Ports

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."

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.