Isolationism

Over the past few days I’ve finally found time to familiarise myself with Scribus, the open source desktop publishing tool for Linux, Macintosh and Windows. I decided to learn as I always do—through the practical experience of an actual project.

For my task, I wanted to try to create an attractive, electronic reproduction of Iain Banks’ novel The Crow Road with the original black and white cover art by Peter Brown. This type of publication is typical of desktop publishing packages and would involve no high-resolution bitmaps as everything would be accomplished through the use of vector graphics.

Scribus turned out to be easy to acquire and install on both Windows and Linux; the latter was installed via Gentoo’s portage system and compiled fine with my 64-bit toolchain.

The tools are at-a-glance what one would expect out of similar software packages (such as the popular and arguably industry-leading package, QuarkXPress, which I am relatively familiar with having used it several times before, during, and after college (although mostly during, and on both PC and Macintosh for that year).

Scribus loaded with relative speed and happily detected all of my fonts, including TrueType, Adobe PostScript Type1 fonts, and OpenType fonts. After loading the interface pops up a friendly “New Document” tab, allowing you to design a new template for your project, open an existing document, or a document recently loaded in Scribus.

Setting up the document was a breeze. By default all the units are in points, but the units are easily changed to any of those units commonly used for design. I had my double-sided document set up in only a couple minutes and was ready to start.

Being familiar with desktop publishing means knowing the ‘best practices’ out of the gates; my first task was to set up master templates for the different page layouts required (about five total for the book), and defining font styles to alter page markup as desired. Setting up templates and default styles was a breeze; everything was as it should be and I had templates ready to go before long. The only snag I encountered was that Guides were set to invisible by default; I was able to drag new guides out onto the layout but they vanished the moment I dropped them onto the page without fanfare. The Scribus folks might think to put a notice or warning if you perform actions on invisible layers in the future.

My next task was to create the vector graphics. Although Scribus has a number of vector-graphics drawing tools, this is not its strong suit; I’d be crazy to waste my time trying to accomplish anything more significant than a basic line or geometryic shape. All of the drawing therefore took place outside of Scribus.

For those who are interested in the process of recreating the cover, the task was moderately simple: Scanned the cover at the highest resolution the scanner would do to a bitmap image, then used the open source package autotrace to convert the image to bitmap. It works quite well, incidentally, and performed quite quickly for the complexity of the source image; The limited input formats (no PNG or TIFF, for example) are overcompensated for by the couple dozen vector output formats.

After cleaning up the drawing in Xara Xtreme PRO then converting the output to SVG, I was able to import my beautiful, crisp SVG artwork into Scribus (which it handled perfectly).

That was about where the enjoyable experiences ended.

The next task was to start fleshing the book out with content, which turned out to be surprisingly painful for a tool whose “job No. 1″ is publishing the written word. Your text import options turn out to be largely useless (csv is only useful for tabled data, plain text files contain no formatting except carriage returns and can run into character encoding problems, and I cannot for the life of me think why anyone would want to import a Palm Pilot text document into a desktop publishing program—although if you do, you’re in luck, because the format is supported); the only available formats approaching usefulness are HTML and OpenDocument formats. I’m very comfortable with HTML because of it’s simplicity, transparency, and ease-of-editing using my favourite text editor, jEdit—so that is what I opt to use to mark up the content for import into Scribus.

This, in fact, turned out to be a phenomenal waste of time. Scribus’ HTML import support managed to get headings right, but got the difference between a paragraph break (<p>) and a line break (<br />) confused and swapped the two, which meant having to code my HTML incorrectly to get Scribus not to screw all the paragraph indents. You would also think that basic tags like emphasis and strong (or italics and boldface for the old school; I tried both) would be supported, but you would be wrong: Scribus ditched them like a bad blind date without a note. In fact, Scribus seems to support nothing more than the most basic block element tags; my attempts to get Scribus to create some additional styles by using classes on some of the tags were also completely ignored.

Then after more digging around on the ‘net, I found that Scribus’ formatting support for the OpenDocument format is substantially better—so much so, in fact, that after using it, I concluded that this is the one and only way it even makes remote sense to get content into Scribus at all (unless you plan to type it all in directly to Scribus, which I wasn’t about to do for one page let alone several hundred). Scribus not only imported all of the formatting, but retained all of the styles as well, creating its own internal styles to (relatively closely) match those in OpenOffice Writer. Of course, OpenOffice is a 90mb download, so if you didn’t already have it installed, it might be a bit of a downer to have to pick up and install to use as little more than a document converter to convert your content into something useful to Scribus.

After that brief victory, it was back to frustration—Scribus became exponentially slower the more pages were added to the document, especially after the document had reached the 30-40 page size (this was, incidentally, on a modern AMD x86-64 machine with 1GB of RAM which was running nothing else at the time). The times taken to load a document also increased in a similar fashion, which started to happen more frequently at this point as Scribus started to crash more readily the slower it became (always with the same helpful error message, “Signal 11 received”).

I did, however, make relatively good progress up to Chapter 4 (just shy of 100 pages), at which point I realised Scribus had done me the “favour” of implicitly linking text boxes which I had never asked it to link (nor were they indicated as being so using Scribus’s own arrow paradigm)—so that now text meant to begin on a new chapter was in the empty space of a text box in the previous chapter. The problem was invisible until Scribus had crashed and I reloaded the document, because Scribus only made the change when it reflowed the content during the loading process.

This is the point at which I gave up; trying to break these pages’ content back out was proving to be impossible because of the speed problems, and I wasn’t about to delete everything and start fresh only to have the problem happen all over again, as Scribus was clearly in the wrong here for automatically linking text frames it shouldn’t have done and has no mechanism to turn this behaviour off, it seems.

The last experience I had with Scribus worth mentioning is the output—I wanted to export the contents to a PDF file, as these are great for on-screen viewing as well as printing, both at home and professionally, and help ensure a consistent appearance across multiple platforms etc. In this respect, I can say that Scribus performed admirably, creating precisely what its built-in previews suggested, and with impressive speed for free software. Scribus also did a great job of embedding fonts so that documents retained their appearance on systems that didn’t have the fonts I had used installed. On the down-side, exporting to PDF is one of the areas where Scribus crashed most frequently, so save your work before you try exporting anything, or you have a very good chance of losing your hard work.

My conclusion: Scribus is fun to play with, but don’t plan on using it for any serious work for a while yet until some of the more serious bugs have been worked out. I think it’s safe to say that the Scribus development team has “jumped the gun” more than just a little by declaring Scribus as being post version 1.0—I would rate it more at a 0.7-0.8 phase of development based on my experience.

To the Scribus development team, here are my top 7 suggestions:

• Fix the performance problems with large documents. Someone already submitted the ticket long ago; time to put this one to rest.
• Better HTML text input support. If anything your HTML support should be better than your OpenOffice support, especially if I’m adhering to strict XHTML (which I was). Arbitrary class support may be a way away yet, but there is no excuse for not (or incorrectly) supporting block elements that have been around for more than a decade.
• Consistent linked frame behaviour. Or at least let me disable the horrible guessing algorithm for auto-linking completely, as it is a liability, not a benefit.
• Improved stability.I know it’s still a work in progress. It crashes way too often to be taken seriously, though, even if you are anal and saving before any ‘risky’ operations, which I was—the smallest thing can still bring the whole application down in the blink of an eye.
• Improved output options. I know that print media is your primary output target, which is great—but this software could benefit greatly from a couple extra output options. My suggestions for a couple additional ‘high-priority’ formats are XML FO and XHTML + CSS, but that’s just me.
• Allow users to append Scribus documents together. That way, I can work on a large document in smaller, more manageable chunks, then append them together for the final output.
• More configurable page numbers. There’s really no reason pagination should always start at ‘1′. If I could automatically add page numbers starting from whatever page I want, I could work on a chapter at a time then combine the resulting PDF pages using a third-party program.

Last, but not least, a big thank-you to everyone who has contributed to the Scribus project. I am advising designers give it some time to mature, but it is a very promising product and I applaud your efforts to keep this software free and readily available for a wide variety of users of different operating systems.