Scribus Team in the Spotlight

Scribus is known as the most mature open source WYSIWYG page layout application. This interview with members of the Scribus core team focuses on upcoming releases 1.3.4 and 1.3.5, standards in pre-press, success stories and many other important issues. This article was originally published in Russian for linuxgraphics.ru.

Let's face the fact - people are pretty tired of the mythical "Year of Linux on the desktop". Many can barely believe that open source software can be used by artists for real work. At the same time whole publishing houses have switched to GNU/Linux. More specifically, Nonluoghi Libere Edizioni has been using open source applications from the very beginning, but PressPeople is a completely different story.

This Portuguese publishing company delivers several monthly and weekly magazines in different formats. Those magazines are devoted to subjects like cooking, teenage life and society, for example. Each issue has a circulation of 20,000 copies or more. PressPeople already use GNU/Linux for all their desktop work except desktop publishing. Thus, twenty plus workstations are used for a variety of tasks like writing, image selection and other editing. They migrated to GNU/Linux with system integrator Angulo Sólido , for stability and cost efficiency reasons.

A pilot project is running for migrating an existing print workflow to Scribus. It started with teaching sessions with end users and then moved on to practical tests with Scribus 1.3.0, where some issues were found. Gustavo Homem, an Angulo Sólido representative, says that most of them were related the GUI usability. He noted PDF exporting capabilities of Scribus have shown no relevant problems so far.

As a result an issue list with client priorities and wishes was produced. After some analysis the system integrator specialists got in touch with one of the most active Scribus developers, Craig Bradney. From this, Angulo Sólido sponsored Craig for some enhancements and bug fixes. This worked out very well: all the improvements to the Scribus code were then made available on the 1.3.3.x and 1.3.4 branches.

The pilot project is progressing successfully, pages are already being printed, as parts of a full colour magazine are already made with Scribus and one of the magazines will be totally migrated by the end of the year. So you may anticipate an update on this story in a couple of months. Now we talk to the Scribus developers.

• Peter Linnell (further as PL) - started with testing early versions of the application, began writing documentation for 0.5.0 (thus, mrdocs nick), he does QA testing, builds RPMs; works as DTP/IT consultant for publishing companies.
• Craig Bradney (further as CB) - started with testing before 1.1.1, did major refactoring of source code, now mostly does bug fixing, enhancements implementation; is employed as a desktop and data centre support technician.
• Andreas Vox (further as AV) - started by creating the first native port of Scribus 1.3.0 to Mac OS X. Andreas is now working on the internals of the new text system; works as a software developer
• Jean Ghali (further as JG) - responsible for the native Windows port, works on colour management and is employed as a software engineer for a printing company.

Seeing Scribus in action in publishing houses is great, but who are the typical users of Scribus according to your experience?

PL: We have no statistics, our users are too broad to generalise - beginners to professionals.

Which real life usage of Scribus was most impressive for you?

PL: For me most impressive is seeing Scribus adopted by commercial newspapers and reaction of groups I demo Scribus to, showing them several books produced entirely with Scribus - a couple are fine art grade books.

AV: I like all publications listed in Scribus success stories for this year, for example. Actually, anyone who did a Scribus document of more than 30 pages is my hero :)

Do you have some usual prioritisation of tasks for Scribus development?

PL: The roadmap defines it pretty well, but along the way new things come along or better fixes get put. Jean Ghali has been doing lots of improvements to SVG import and colour management, which are much better than before. Sometimes, it is simply a developer's itch or a new feature request that someone looks at and says, "I'll do that now".

What does testing of release candidates look like? Is it somehow automated? How often do you manage to test output from Scribus on hi-end RIPs?

CB: We do use code profiling and checking tools of course. Some open source like Valgrind and other proprietary ones too. There is no automated testing yet, though it is planned. Experience helps us to know where to look for issues with new code. Plus, we now have several thousand test files either purpose built or some which users have submitted as test cases with bugs. Both give us a realistic range of files which exercise Scribus in all of its capabilities.

Moreover, we are lucky to have a small, but dedicated and adventurous team of users to test the newest unstable code, and access to a range of special software like PitStop and RIPs to check on output. Now that Scribus is actually being used by end users for commercial printing for a wide variety of tasks, we know the output is correct or we would quickly hear from end users.

In the few cases where there were issues, we have a) found older hardware/software at the commercial printer an issue, b) end users misunderstanding PDF/X-3 and c) If there was an issue with Scribus' output it is a high priority for the team. We basically stop coding until the bug is fixed, but this has only been for one or two corner cases.

A while ago at Scribus Developer Blog you provided some quite impressive charts from the bug tracker. How do you manage to keep open/closed ratio that high?

AV: I think as a whole the team is very good about managing and prioritising bugs. We generally test each case quickly after submission. In the case of features, we tend to fix the easy ones quickly and move on... Some features need to wait as other parts of the code may need rewriting or new classes added before a feature can be implemented properly.

CB: We chase bugs constantly. The tracker is open 24x7 on my development boxes and we go scouring through the tracker regularly looking for older requests or bugs that based on more recent code developments are now "low-hanging fruit". It can be hard to drop the count, with the onset of so many new users on Windows and OS X, the request count has jumped quickly. However, our 1.3.x roadmap covered a large scope of requests for both the novice and pro publisher so we are on track to close a lot of issues when we get to the later 1.3.x releases.

Some of Inkscape developers are working on a high level library for maths with regards to vector graphics that can be reused by other apps. Are there such projects in Scribus (or planned)?

PL: Not at the moment, but of course we would be interested if it were useful for Scribus and I am sure we would have good cooperation from the Inkscape developers, as we have for a long while. As a whole I think all of the developers who work on open source graphics applications are quite collegial.

Some experienced users of Scribus did a thorough usability test of GUI a while ago. What is the status of addressing/fixing issues that were discovered?

PL:We have done some of the changes already. Some will need to wait for underlying code changes. We also discovered some recommendations would need to wait for the improved widgets in Qt 4. There are some other usability efforts under way with third parties, though nothing to announce yet. Certainly, we do care quite a bit about usability in the sense of trying to balance a need to have sometimes advanced specialised functionality, without overwhelming new users with options which cannot be easily understood.

However, 'usability' is often a misused word, especially when it comes to some open source applications. To me usability has been a code word by some to strip an application of a) configuration options or b) blindly follow the mantra that simpler is better. Well, yes to a point. I've used a number of desktop environments - some your readers may not even have heard of, but I've been frustrated more than once with the OS X GUI too :)

A powerful application like Scribus, a CAD program, or Quanta, for example, pre-supposes some knowledge of the subject at hand. If you don't understand HTML or CAD, these kinds of applications will just frustrate you. It was not until I learned some HTML and PHP that I began to appreciate the efficiency and power of Quanta. Now that I do understand the subject, I find Quanta a wonderfully intuitive app. But I am guessing usability experts may not always like it in the traditional sense.

Getting back to Scribus, our usability is not just focused on making Scribus accessible to new users - that I think we do well enough in the main. We also need to consider what is efficient for an experienced user and also those who may have lots of experience with other page layout applications.

AV: Talking of OS X, the Qt 4 port will also allow to fix some remaining GUI issues with Scribus/Aqua (like menu handling, slowness, colour shifts, missing installer etc.) in 1.3.5.

Imagine that the roadmap is done. Where would you go further to? Would you experiment with workflow and usability like the developer of dtpblender or would you keep adding import/export filters?

PL: Given what we have outlined for the current roadmap, I would imagine we would look towards enhancing automation and work on refinements of the importers. Importers are notoriously difficult to get 100% perfect and file specs change over time.

AV: If the roadmap is done, we'll just write another roadmap! :-)

Which open source applications for the printing industry are currently missing, and which of them are critical? Is the Scribus team planning to address these issues and develop such applications, e.g. a Pitstop analog or a high-quality imposition tool?

PL: There are a handful of special tools which I think will more than likely remain proprietary for a while. Why? They have a small audience and the developers themselves need to have a lot of specialised knowledge about printing, imaging and PDF/PS. As for imposition, we are going to implement it a bit later directly in Scribus.

What do you think about Microsoft's initiative to replace PDF with XPS, the XPS itself and its strategy of semi-opening specs? Is import of OpenXML documents planned to be implemented in Scribus using existing specs?

PL: XPS has some interesting features, but as yet, we will have to see what the uptake is. PDF is not going away any time soon, there is too much serious investment at least in the printing industry in PDF. It solves many problems which were painful and expensive to overcome in the past. When I mean investment, I am speaking of the ways printing companies have built their entire printing plant around PDF. Moreover, PDF for print continues to a) have better more sophisticated tools b) it is being extended with functionality like JDF (Job Definition Format) c) the specs are evolving to adapt to more usable, consistent colour management, for example.

As for OpenXML, there are already some limited means of importing it in Scribus and that certainly will improve in the future.

Scribus doesn't support exporting to PDF 1.6 yet, which means, for instance, that OpenType fonts cannot be embedded and thus text is automatically converted to outlines. So, what plans do you have for support of PDF 1.6?

PL: We keep up with any features we see that users will see of benefit. We don't have a release date from companies like Adobe but for example, we have already seen some things in the PDF 1.7 spec that are interesting and we will support such features as required. Right now, we support a large part of the features of the more common and widely used PDF versions. So, having a combo-box item for "PDF 1.6" doesn't make as much sense as a better text system now. OTF embedding is very new in prepress, not all of the hardware supports it. We will address things like this at a later stage of development.

CB: We want to support the requirements of users, not just chase numbers. Some of the versions of PDF target certain use cases that are not necessarily beneficial to the typical Scribus user. Having said that, we follow the PDF specification releases closely to check for new and interesting features.

One of well-known "limitations" of Scribus is no licensed Pantone swatches out of box. Is it a real showstopper for DTP? What are the prospects of the OpenColor initiative?

PL: This is somewhat of a red herring. Spot colours are used less often than one might think. For corporate logos or for certain jobs, yes it is essential, but there is nothing preventing a designer to manually specify the inks. Even then, Scribus can import proprietary named inks, which is what spot colours really are - inks with proprietary names. Scribus does this following the published PS and PDF specs which define how spot colours are used. Scribus' support for named spots is very thorough with no limit to the number of "plates" used. The separation previewer is limited to 16, I think, owing to the limit of the tiffsep device in Ghostscript. The next version of Ghostscript, I believe, will remove this theoretical limit.

While we would welcome working with ink companies around the world, it is honestly not something we have expended a great deal of effort. However, the behaviour of some companies seems down-right silly. Offering open source applications access to the colour palettes would only generate more sales of their inks and more support for their inks.

Which features of the new 1.3.4 release are most exciting for you?

PL: The next text layouter, which will be refined even more in 1.3.5+, simply put, makes text look so much nicer. The transparency effects and the new character styles are two others. Plus, pre-press needs such as bleeds, crop marks, registration and more are all in this release. This is going to be a big release. There are lots of smaller changes and updates.

As I understand it, new transparency effects have become possible only with Cairo 1.2.x that can be chosen instead of libart at ./configure stage. You might have read a report on the results of a Cairo/Arthur benchmark. According to it Arthur shows better results with regards to speed. Are you going to support this engine as well?

PL: Yes, we've seen this report. When Cairo has reached rough parity in speed with libart, we may make it the default engine for Scribus. We are going to port Scribus to Qt 4.2 during the v1.3.5 development cycle. We may remove support for libart and add support for Arthur. We'll keep support for both of them, though we don't know yet for how long.

Could you please tell more about new the text system? What improvements should we anticipate?

AV: The new text system brings both internal and user visible changes: a) refactoring of existing code to make it more manageable, b) implementation of a new linebreaker which optimises whole paragraphs, c) implementation and use of a shaping engine which allows ligatures and advanced OpenType features for Latin text and provides infrastructure for international shaping. Most of the nice visible features will appear only in 1.3.5. Version 1.3.4 will only support the new style system (char styles, for instance) and optical margins, maybe special spaces, word tracking and better justification will come along, but no promises.

So, that means that with 1.3.5 we are going to have specific OpenType features supported?

AV: One by one and not all at once. OpenType features should be applied in a certain order, and some are language/script specific, some are discretionary, e.g. swash glyphs or minuscule numerals. The OpenType spec suggests an order for the features, which should be on by default and which depend on language/script. So we'll first pull in HarfBuzz to get access to the OpenType tables, then implement the default features, then some of the most requested user-selectable ones.

Colour management is already quite mature in Scribus. Are you planning any further substantial changes?

JG: Well, yes - a different internal design. Basically we will abstract colour management. In the future, that will allow us to provide support for several colour engines. I think for example to ColorSync on OS X and ArgyllCMS on Linux. The first benefit of this new design for users will be colour management enabled by default. We plan also to implement colour managed RGB output, one effect being better printing capabilities on inkjets.

How would you rate the current impact of Scribus on printing industry? Do you have some kind of vision for Scribus?

PL: Hard for us to know about impact in the printing industries. Mostly, we are under the radar because our PDF is highly conformant and usually "Just Works". As for a vision, I think it's simply to make the best page layout app which runs on Linux, Mac OS X and Windows and to do things which are innovative and which differentiate us from the rest. Not just different, but cool and useful like the way Scribus handles interactive PDF.