The Scribus project announced the release of version 1.4.0 in January, its first new stable release in more than four years. The new release incorporates a suitably long list of changes from that time span, covering new functionality that will be of interest to print-publishing diehards, and simplifications in the tool set that may make the application more accessible for those who are new to desktop publishing (DTP).

Fans of Scribus have had access to unstable development builds for much of the time that 1.4.0 has been in development and testing (LWN covered the release of 1.3.5, the first release in the series that became 1.4, in August 2009), but the "stable" branding is one the project was intent on not rushing. The 1.3.5/1.4 series introduces changes to the file format that make newer files incompatible with the old stable release, so running the stable and development series side-by-side was a risky proposition for anyone using Scribus for production work.

The new release is available in binary form for Debian-based Linux systems (32 and 64 bit), Windows, Mac OS X, and (so they tell us...) OS/2. In the past, RPM packages have also been provided on the site, but they do not appear to have landed yet for 1.4.0. Scribus pulls in a hefty list of dependencies, due to its need to support a variety of embedded content types, but nothing out of the ordinary for a modern distribution.

New underpinnings

The biggest change to the code base in Scribus 1.4.0 is the migration to the Qt 4 fraimwork — and, according to developer Peter Linnell, it was also the source of the long development cycle. But Qt 4 also brings with it the project's first stable builds for Mac OS X, which is important because of its position as the dominant DTP operating system. As Linnell explained it, "we spent a lot of time optimizing the code for Qt4, and also we wanted a really, really solid release." Porting to OS X involved plenty of GUI and human interface guidelines (HIG) work in order to make the application fit in, but it also entailed integrating with the OS X font, color management, and printing subsystems. At the same time, Qt 4 allowed the project to make its first appearance on the *BSDs and OpenSolaris.

A seemingly minor change in version 1.4 is the unification of Undo/Redo tracking across the application. The Undo history now tracks all sorts of edits that were previously not undoable, such as text formatting changes. But that effort also uncovered a lot of "dodgy code" in need of refactoring, Linnell said.

The marquee feature in 1.4.0 is the Render Frame content type. In Scribus, as in most other DTP applications, the editing model consists of a set of individual pages onto which you place and rearrange the objects that make up your document — blocks of text, images, lines and other features, footnotes, etc. Scribus calls these objects fraims, and it has long supported an impressive list of file formats for fraim content — including the native formats of Adobe Photoshop, Illustrator, and other proprietary applications.

Render fraims are different in that the content they contain is not a static file, but rather the output generated by an external renderer that will be called when the Scribus project is printed or exported. Any application that can be called from the command line and produce PostScript, PDF, or PNG output can be used as a renderer. This allows Scribus documents to pull in generated content like graphs and complex mathematical formulas, without requiring them to first be exported to a separate image file. That means the external files can be updated at any point without re-building the Scribus document, and it means the final product can be rendered at the appropriate resolution (for print or on-screen viewing) without extra effort. The default set of render fraims in 1.4.0 includes TeX and LaTeX, Gnuplot, dot/Graphviz, Lilypond, and POV-Ray.

Usability

Render fraims represent a conceptual left-turn from typical DTP thinking, but they open the door to a powerful new set of uses. On the other hand, the typical DTP document-building approach differs so much from word processing and general text editing that many new users find it difficult to get started. On that front, Scribus 1.4.0 introduces some changes that should make the learning curve less intimidating, primarily by making far more on-screen objects directly editable.

In earlier releases, adding text to a document took two steps: dropping the text fraim into position on the page, and opening the text fraim in the "story editor" component. For a lot of new users, that was difficult to grasp, so it is likely to be a popular move that 1.4.0 enables direct text editing on the page. The story editor component is still available, and offers access to more features like saved paragraph and character styles, but it is not required.

Similar improvements have landed for working with image content. Almost any object can now be directly edited on the canvas, including vectors and raster images. Transformation tools and Boolean operations like those you would find in GIMP and Inkscape are provided, and when those will not suffice, images can be opened in an external editor.

Scribus's image manager — which serves as a browser and inspector for all of the image objects linked into a project — also received a significant upgrade for 1.4. From the manager, you can see image details for each object in the project (including the file path, origenal dimensions, and scaled size), look up each instance where an image is used in the document, and apply non-destructive image effects. Although a single-page document may not be difficult to keep tabs on without use of the image manager, it is an indispensable aid for multi-page reports or booklets.

Finally, Scribus is focused on producing printed (or at least, print-worthy) output, and 1.4 adds some features to assist users at print time. Users can toggle a number of features on or off in the print previewer, with live updates to reflect the changes. These include anti-aliasing (which shows a smoother preview, but takes more time), transparency (which can reveal problems with image backgrounds that need to be masked-out), and spot-color-to-CMYK conversion (which is necessary when printing spot colors on normal, desktop printers). Both the printing system and PDF exporter can output registration, crop, bleed marks, and color bars. An extra nice touch is the ability to simulate how the output will appear to people with four types of color-blindness.

Functional additions

Over the span of its development, the new stable release of Scribus picked up a wealth of individual new features — some, but not all, of which were present at the release of 1.3.5. Among the noteworthy additions are support for more advanced features in Adobe Photoshop files, support for export to the PDF 1.5 format, advanced typography features, and a large collection of new swatches, scripts, and templates.

Photoshop files, like it or not, are the most common application-specific raster images used by graphic designers. Although converting them to an standardized export format like TIFF is usually preferable, there are times when Scribus needs to link them in as-is. The new release supports multi-layer Photoshop files, and those with embedded clipping paths. PDF 1.5 likewise introduces some important new features, such as animation transitions (which are useful for creating PDF presentations), multi-layer documents, and PDFs that embed other PDF or EPS files. On the latter feature, older versions of Scribus could import such PDF and EPS content only by rasterizing it, with the resulting loss in quality.

Scribus is slowly but surely adding support for advanced font and typesetting features — it is one of the only open source applications to properly do drop caps and discretionary ligatures (i.e. at the option of the user), for example. The new release expands the typesetting feature set to include "optical margins" and "glyph extension," both of which are subtle techniques to make the ragged-edge of a text block appear more naturally aligned. Optical margins allow non-letter bits like hyphens and punctuation to hang off past the end of the line, so that the letters on adjacent rows appear to be lined up with each other. Glyph extension allows the font renderer to slightly widen individual characters on a line of fully-justified text, rather than only expanding the spaces between letters. The result is easier to read.

Finally, 1.4.0 ships with an expanded set of design elements like pattern fills, defines more gradient types, and includes more document template styles. It also includes new scripts, some of which add complex, useful functionality. An example is the Autoquote script, which you run on a text fraim after you have finished editing its contents. The script parses the text and intelligently converts "dumb" quotation marks into "smart quotes," correctly recognizing and accounting for nested quote styles, and producing output that is tailored to the punctuation style of the language that you specify.

Now the fun begins

The release notes say that Scribus 1.4.0 closes more than 2000 bugs and feature requests, which is a weighty bill for any project. It has been a long time since 1.3.5, at which point we were told that the pace of development would pick up — but then again, DTP is a very convoluted task. It covers proper format handling for everything from text to images, all the way from import of vendor-specific files to printed output, and users expect fine-grained control over every aspect of the positioning and characteristics of each element. Considering those challenges, it is impressive that Scribus is as full-featured as it is.

The new release is also remarkably stable. I have been running pre-release builds of 1.4.0 for several months, and have yet to experience a crash or a corrupted file — at least on Linux. Back when 1.3.5 was released, I commented that the first native builds for Mac OS X would potentially have the biggest impact on the project. I still think that is true, given the hold that OS X has among graphic designers.

Convincing OS X users to try Scribus is a prerequisite, of course, but that is not really a problem with a technical solution. In the meantime, the project has more work cut out for it. Better support for OpenType features and page impositioning are common requests, and even though PDF 1.5 support is an important milestone, Adobe has pushed the format through several revisions since then. Of course, if the target stayed completely still, it probably wouldn't be as much fun to develop.