[dot] FOSDEM 2005: Scribus in the Commerical DTP World

[Dot Stories]

URL: http://dot.kde.org/1108130774/

From: Jonathan Riddell <>
Dept: publish-and-be-damned
Date: Friday 11/Feb/2005, @15:06

FOSDEM 2005: Scribus in the Commerical DTP World
================================================

   In the second in our series of interviews with speakers in the FOSDEM
KDE developers room [http://www.fosdem.org/2005/index/dev_room_kde]
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 [http://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:

 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.  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. It runs on more platforms.  I can't run pro DTP apps
on what I consider a superior operating system.  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.  It is less resource intensive. You can run Scribus easily on
a PIII.  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. 
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.   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
[http://docs.scribus.net/index.php?lang=en&sm=dtptoolbox&page=toolbox]
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.