FOSDEM 2005: Scribus in the Commerical DTP World

In the second in our series of interviews with speakers in the FOSDEM KDE developers room Scribus developers Craig Bradney and Peter Linnell talk about the state of desktop publishing on Unix and its acceptance in the commercial DTP World.

Please introduce yourself and your role in Scribus

(Craig Bradney) I have a consulting company based in Luxembourg. My principal areas of expertise are enterprise network, development and project management. My role is kind of all hands, daily project management, running the bugs tracker, working on code refactoring, testing and managing most of the project's infrastructure. I started actively participating soon after Scribus 1.1.0 came out.

(Peter Linnell) I am an independent IT consultant principally for DTP and publishing companies with expertise in cross-platform networks and business processes. My role is first writing the docs and testing, especially bugs and PDF/PS output from Scribus, along with web-mastering www.scribus.org.uk, our portal. I've done this since the early days of Scribus, before there was an organized team, just Franz Schmid coding by himself.

Scribus recently released version 1.2.1, what is new in this version?

(CB) The major news in 1.2.1 is a new OpenOffice.org Writer and Draw importer. Underneath this, there is a new API which makes writing import filters much easier. This is thanks to Riku Leino, our newest team member. The other major news is commercial support for Scribus. That means a) we're confident it is reliable enough and robust enough for commercial applications, b) we have the experience and know how to provide the kind of support needed by institutions or companies large and small.

You are now offering commercial support for Scribus, what sort of services do you provide?

(PL) Both my and Craig's companies will work together to provide whatever services a company or institution needs to properly implement Scribus as a print publishing platform. That can mean Scribus as the main platform or along side existing publishing apps. We also have at our disposal other specialist consultants who are world class experts in areas like, for example, enterprise printing. Other team members will be able to write customised parts if requested and feasible. Note, by inference, we will be supporting KDE desktop in a commercial setting :-)

Scribus uses pure Qt, have you ever considered making Scribus also use KDE?

(CB) We are planning this as a compile time option. No definite date, but we see KDE integration for those who wish to have it as a big plus. Stay tuned. :-) This is something often requested by the KDE diehards out there, and fair enough, KDE is a great platform which most of us use too. The issue comes when you consider the cross platform implementation of Scribus into Mac OSX via Fink (and natively in future) and possibly Windows. Scribus runs on various flavours of *NIX, such as HP-UX, IRIX etc and there's no guarantee of KDE there either. A compile time option for use of native KDE file dialogues and KIO slaves, etc seems to be the best option.

How does Scribus compare to the proprietary competition?

(CB) We do not think of Scribus really as competition for others, more providing the best DTP experience for the Linux/Unix world. Our focus is not to make a feature by feature clone. It is interesting to see some of the mailing list threads by long time users of other DTP apps using Scribus for the first time. They are quick to point out 'Well, Scribus does X and I am used to Y. Why?' Often the reply is 'Well, Scribus does Y, because it is the $*nix, $desktop, Scribus way of doing things.' This an interesting form of comparison as one can see where Scribus shines.

(PL) That said, I use or have used most every professional DTP app. Scribus strengths:

1. It is open source and all the goodness that brings with it. Not just the price, but the ability to interact directly with developers, the community support, frequent releases with new features and the transparency of the process.
2. I think users of other commercial DTP apps unaware of Scribus would be floored by the level of support Scribus users get - for free. Our commercial support will be even better and more comprehensive.
3. It runs on more platforms. I can't run pro DTP apps on what I consider a superior operating system.
4. I can say with a straight face its PDF export quality is commercial grade. It is, in my opinion, the best in OSS. It matches up and/or is superior to many pro DTP apps.
5. It is less resource intensive. You can run Scribus easily on a PIII.
6. Its file format is very robust - almost corruption proof - a big problem for many DTP apps and especially where networks are concerned. I've been paid very well to beef up networks and customise the clients to make them more reliable for certain DTP apps.
7. Cross-platform Python scripting. This is a sleeper as Python allows you to extend Scribus with the tons of Python modules available. Cross platform scripting in pro DTP apps is almost non-existent.
8. We have better looking developers :-)

How many people are working on Scribus and where do you find such talented developers?

(CB) I think one the secrets has been each one of the devels has very complementary strengths. The other attraction for members is the overall friendliness of the community, whether on the mailing list or on IRC. We have made a serious effort to make Scribus approachable to those either new to DTP or Linux. It makes contributing to Scribus a real joy. The other interesting bit is we are probably slightly older overall than those in the typical OSS project. Our experience in DTP, corporate IT and teaching probably help keep us focused and well grounded on practical issues.

(PL) The main Scribus Team is six officially. It really did not become an official team until we dragged Craig along. We would also be remiss in not acknowledging some important contributions like Steve Calcott's font sampler script complete with GUI. That showcases how powerful the Python scripter can be. Another would be Alex Moskalenko who took over maintaining the Debian packaging. He made our Debian issues just disappear. Craig Ringer has contributed a macro system for Scribus and helped with the scripter. There are many many others who have helped in code, translating and in serious real world testing. Honestly, the list is getting to the point where we have to start saying "thanks to all those who we have forgotten to mention".

Have you looked at how the changes in Qt 4 will affect Scribus?

(CB) Yes. Already parts of Scribus are being rewritten to accommodate the changes. Much of the menu code for example has been completely rewritten in CVS to accommodate this.

Scribus is not as user friendly as a word processor, for example you can not apply formatting to individual words. Have you considered including such word processing features?

(CB) So called, character based styling is coming in the next development version. Please note though that Scribus is well served by the use of well thought out styles prepared in advance - a well understood process used by almost any serious publishing application. You can apply formatting to individual words perfectly well, it can be a bit cumbersome at the moment given the mixed advantages of paragraph styles and per character selection. Also, Scribus has a built in Story Editor which is designed to make the text import/styling efficient. By the same token, you could also say most word processors are not user friendly to DTP users...

What have been the experiences of people using Scribus for real world publishing?

(PL) The largest challenge is some printer's equipment/work-flow do not support the more advanced features of PDF 1.4. Really. In one case, I got urgent messages from a publisher saying the printer had serious problems with the Scribus PDFs. The printer had one of the world's most advanced pre-press systems with PDF/X-3 support (Scribus was the very first to support PDF/X-3.) The printer's software feeding it was ancient - MacOS9 and Acrobat 4. I sent them special pre-flight PDF certification reports for the same files. That quickly convinced them the Scribus files were not the problem.

(CB) Overall, despite most printer's unfamiliarity with Scribus, its worked well. We have books published and newspapers using Scribus. I have some nice examples from a classical music group - CD covers, tickets, posters etc, the end result is stunning. We have had no real show-stoppers and no missed deadlines. I edit a car club magazine here in Luxembourg with Scribus and have it commercially printed in Australia with no real issues.

Also, two of our translators are folks who are in commercial pre-press. They have been really helpful to other printers and our users on the mailing list.

Scribus currently recommends Acrobat as a PDF viewer. Have you looked at the impressive kpdf in KDE 3.4?

(PL) Yes. It is very impressive to see the improvements. Thanks to Kurt Pfeifle, well known for his work with NX and KDE printing, I was testing the CVS HEAD version of kpdf before the 3.4 alpha was released. I recently added it to my Toolbox section of the docs. Still, we have to recommend Acrobat Reader to be specific, as it is still the most reliable viewer for Scribus users. Adobe Reader 7 should emerge sometime soon from its' public beta. If it is comparable to the released Windows or Mac versions, this will be a major gain for Linux desktop users.

The DTP Toolbox section of the Scribus docs outlines my preferred recommendations (and reasons why) for certain graphics apps. The main idea was to highlight those which are especially helpful alongside Scribus.

(CB) We do get a few people in IRC getting viewing "issues" with some PDFs from Scribus, but until the free PDF viewers can catch up to some of the features in Acrobat Reader we just cannot recommend much else. Some people simply refuse to install the "non-free" Acrobat Reader as a matter of principal. It seems, especially with KPDF in KDE 3.4, we might be approaching this time where we can really suggest an alternative to Acrobat Reader. The devs of KPDF and others shouldn't stand still though :), we have PDF 1.5 and 1.6 on the target. In fact, we could have had PDF 1.5 support ages ago, although we did not implement it as no viewer on Linux could view it at all.

What is the status of Scribus on Windows and what have been the problems with porting Scribus to Windows?

(CB) The KDE-Cygwin Team has come up with a set of patches to enable Scribus 1.2 to compile and run under Cygwin. We really appreciate their interest and it is indicative of their project's progress that a full featured application can run with the KDE-Cygwin project. They have solved many of the porting issues and improved performance dramatically. As for a pure Windows port, the greatest constraint is developer time and the fact that we are fully involved in working on the next 1.3.x devel series.

We do not want anything to distract from taking Scribus to the next level in features, usability, stability and performance. We will announce the 1.3 Roadmap leading to Scribus 1.4. We are still discussing this amongst ourselves and, as always, carefully considering the valuable input we get from all sides.

What is your view of the future of DTP on Linux and Unix?

(CB) Well our aim is not to replace wholesale other applications, but to provide the best DTP experience for Linux users - to provide the same kinds of tools users have had on other platforms and to use the inherent strengths of OSS and Linux/Unix to Scribus' advantage. For many many people, businesses and institutions it's a compelling solution with low maintenance and high reliability. Also, more and more design people are active on the development side. For example, two of the main Inkscape coders are also graphics pros. This helps to bridge the gap between developers and users' wants and features.

(PL) The technical side of DTP is coming along nicely. GPL Ghostscript 8.15 which was recently released is a major leap in capabilities. We hope all distros will upgrade as soon as possible. Many other applications are understanding the need for and are starting to implement colour management. Many other things which were painful on Linux like font management are now solved. KFontInstaller since KDE 3.3 is fabulous. For end users its easier than even proprietary font managers. What could be easier than: Select font > right click > Install font? The overall quality of end user graphics programs is improving steadily.

Right now, I would say the biggest weakness from an FOSS point of view is there are few good high quality fonts. It is one of those areas which requires tremendous amounts of QA to make them reliable in the commercial print world. This is highlighted throughout our documentation.

Lastly, there is much goodwill amongst the various teams and projects involved in graphics. Witness our cooperation with Inkscape which uses a different toolkit and sometimes different style of doing things. We do share and learn from each other. When I first worked with Linux, the concept of DTP on Linux seemed very distant.