SEP
29
2004

Interview with Scribus Team

Used in production workflow of a commercial newspaper! Chosen as as one of their 'Cool Applications' by Trolltech!
Nominated as finalist in the category 'Best Office Software' for the Linux Format Awards 2004! More than 750 bugs/feature requests closed since the 1.1.2 version! The professional DTP application Scribus is steaming ahead! Curious about the Scribus team? We have an interview for you originally conducted by the kind people of Golem.de just before the Scribus 1.2 release.

.imgboxrt{
border:1px dotted #000;
float:right;
margin-left:5px;
margin-right:10px;
}

.imgboxlft{
border:1px dotted #000;
float:left;
margin-left:10px;
margin-right:5px;
}

Scribus moves forward to a stable release 1.2. What was the premier
focus during the development?

Craig Bradney: To bring Scribus up to a level of usability, reliability and
functionality where all levels of users can use Scribus as a serious DTP
program on the GNU/Linux and *NIX platforms. We've closed approximately
700 bugs/feature requests since we put in the bug tracker after 1.1.2
was released. It's easy to see we have really put in the hours over about
10 months to knock the bugs on the head and introduce some really great
features to Scribus.

Scribus addresses an area with well established competitors. What's
your main goal - to fill a gap in within the software portfolio for
Linux or to drag people away from other dtp software?

Craig Bradney: Both. The DTP area of software on Linux is not well supported so there's
certainly a gap to fill there. There are many people that just have that
last area of needed software to be filled on Linux so they can jump ship
into the FOSS world. This has been the case for some of our developers,
and also for many many users we have spoken to.

Peter Linnell: In the end, we really do not think in terms of "competitors", more:
"What can we provide to our end users and for ourselves to make a great
DTP application which is primarily, though not exclusively for Linux?"


The pages on the canvas show off the transparency tricks and gradients
now in Scribus

Do you plan to support other operating systems than Linux?

Craig Bradney: Scribus currently runs on various flavours of *NIX. We know people have
tried Scribus on up to 128bit processors, and on BSDs, AIX, Mac OSX via
Fink, and Windows 2000 via Cygwin. We do have plans for a native version
of Scribus on Mac OSX and Windows, although no firm dates or development
processes have been put in place for those at this point. Linux is our
focus for now.

Peter Linnell: Scribus works very well with newer Macs on Fink in my experience. We
have a really good maintainer for our fink packages, Martin Costabel.

Scribus took a jump start and got lot of attention with the release
of Scribus 1.0. But, is the software ready for a production use today?

Craig Bradney: Yes, for sure. Certainly there will always be things people need and of
course the needs are higher at the top end of the DTP market. We know of
countless semi-professional magazines and personal publications in
production with Scribus. In more recent times we had also the pleasure
of helping a weekly commercial newspaper (20,000+ copies) in the USA get
off the ground using Scribus.

Scribus 1.2 is lights years ahead of 1.0. We are hoping a lot of people
can now switch to Linux using Scribus for their DTP work, or finally
just achieve great results with a DTP program rather than trying to
achieve these kind of results with a wordprocessor.

Peter Linnell: One of my magazine publishing clients has also allowed me to
install Linux workstations and Scribus alongside their specially
configured DTP workstations, both Mac and Win2k. They have been really
really supportive of allowing me full reign in a real world pre-press
department of a 4 color magazine. This has been invaluable to test and
to study Scribus' behaviour along side and within other DTP
applications.

I have done quite a bit of testing of Scribus PDF and PS files with
specialist pre-press pre-flight applications, as well as an advanced Fiery
RIP. These pre-flight tools examine the files for conforming to published
specs and commercial printing norms. Scribus files are *highly* conformant. In
my professional opinion the output is in some areas superior to commercial DTP
applications. We also have three commercial printers on our mailing list who
have verified the same results using imagesetting equipment.

Who is developing Scribus and is any company directly supporting the
project?

Craig Bradney: In order of joining the project:

  • Franz Schmid (Germany) - original author, main coder, "Our Linus"
  • Peter Linnell (US) - docs writer, tester, webmaster for www.scribus.net, DTP IT consultant
  • Paul Johnson (UK) - code tester, reviewer, has done lots of work on performance and profiling, setup CVS and the Salford web server.
  • Craig Bradney (Australian living in Luxembourg) manages IRC and the bug tracker, bug testing, docs proofing, webmaster for docs.scribus.net
  • Petr Vanek (Czech) - has written the special typography plug-ins, and other plug-ins, also works on the Python Scripter API within Scribus.
  • Riku Leino (Finland) - wrote the new templates plug-in, the html importer plug-in and is working on the text importer API.
  • The School of Music, Media and Performance, University of Salford, UK -
    webhosting, CVS and FTP
  • Netraverse (with Win4Lin for testing purposes).
  • Linux New Media AG (Germany) made it possible to present Scribus at
    CeBit 2004 and support us with nice articles in their magazines :)
  • Peter and Craig have their own companies which help support Scribus
    in various ways. We are discussing how to offer commercial support for
    Scribus in the future.

Mostly the project moves ahead under its own steam fuelled by the
enthusiasm of the team and the various contributors, translators, and
help and encouragement from users out there. Of course, we are all lucky
to have supportive families too!

We have spent countless hours every single day since 1.0 was released.
Adding up those hours would be too scary to do. We have added some great
team members and had the support of contributors who all put in as much
to the project as they can.


A look at the new story editor in Scribus 1.2 with Chinese text. Scribus supports Unicode extensively. Indic Script and full CJK support are on the todo list.

What about compatibility with other DTP software applications?

Craig Bradney: In terms of import/export type functionality, none really, but thats not
just a "we can't do it" answer. It fits more to the idea developed from
experience that even commercial companies with full access to sources of
older versions of products just can't get import and export filters 100%
correct even with their large teams and budgets. In most people's experience it's faster and a much more accurate result is achieved when
you take the leap and switch software.

Peter Linnell: DTP files internally are very complex. Far more than most application
files. Second, EPS and PDF is a more common means of export/import. Scribus
does very very well on that mark, in some cases more capable than commercial
DTP apps. For example, many EPS files can be imported, then edited as
native Scribus objects. No other page layout application can do that.
Third, the commercial print world (or at least the smart ones, in
my opinion) is embracing PDF as an exchange format. PDF solves many
interchange/cross-platform issues, especially fonts. Scribus, with its
powerful PDF exporter makes cross-platform issues disappear.

Those who say we should have a importer for DTP app X, belie their
inexperience with DTP file conversions. I have rarely had good luck with them,
except for the simplest files. Even importing between different versions of
the same app can be tricky. Moreover, this would require reverse engineering
a closed and complex format. It is our thought that precious developer time
is better spent on making Scribus better.

The fact that Scribus generates excellent PDF is the true "compatibility"
test. In some cases, it is not Scribus, but other DTP apps which are lacking
in newer PDF feature support. We have run across this in supporting the
handful of newspapers which are now using Scribus. Their printers were using
older versions of pre-press tools which could not support all the PDF
features Scribus is capable of creating. This has also been an issue for the
latest versions of other commercial DTP apps. We have made notes in the docs
addressing this issue.

Craig Bradney: As for usage patterns, we want the general methods to be similar for DTP
users to come across to, but most of all we want our features and ideas
to shine through very strongly.

Where we have and will concentrate in future versions is on support of
formats that do make sense to give access to. For example, we have a new
import system, thanks to Riku, which allows us, or anyone, to write simpler
code and make an import filter for your favourite text or graphic file
format.

What are the most important needs that you plan to address after the
1.2 release? Will there be a 1.2.x series?

Peter Linnell: Yes, Franz has already branched 1.3 and 1.2.x. So we plan to release a
1.2.1 version in the coming weeks. Mostly bugfixes, but also new import
plug-ins from Riku. Petr Vaněk is working on extending the Python scripter.

Riku Leino: With 1.2 we started on single plug-in system to group those plugins
together which handle the same type of things. The first such plug-in group
done was the Get Text plug-in API for importing formatted text to a text
frame. After I finished the html and csv importer plugins, there is now
an OpenOffice.org Writer importer under development which will most likely
be included with 1.2.1.

Craig Bradney:
To name just a few:

  • Higher end DTP needs such as true on-screen joined facing pages to name
    just one
  • PDF 1.5 support
  • Higher level of CMYK image import support
  • More import filters for text formats and image formats
  • Support for larger organisation usage (leaving this one wide open.. we
    have nice plans shall we say)

The wish list for the 1.3.x development series goes on forever.. we
discuss all the nice things we want for hours some days. Look forward to
an updated roadmap later this year :)

Comments

The link to the German Version on golem.de:
http://www.golem.de/0409/33794.html


By MaX at Wed, 2004/09/29 - 5:00am

better Vanek than Vaněk


By jose marin at Wed, 2004/09/29 - 5:00am

better use working browser + font.


By Asdex at Thu, 2004/09/30 - 5:00am

And even better yet, if W3C standards are respected!
Not a browser/font problem, but a coding error


By Cinabrium at Thu, 2004/09/30 - 5:00am

I must say that Scribus does look very good, and frokm my testing a few weeks back it I found no problems with it. It does take a while to get used to the way Scribus works, but I like the general idea.

However, I found Scribus to be really slow, especially when moving frames or doing other "basic" activities that involved the main canvas being redrawn. I'll however give Scribus a spin when we make our annual wall calendar from our digital photos. I think it's going to be more fun than OpenOffice. :)


By chakie at Thu, 2004/09/30 - 5:00am

That's true. Scribus is extremely slow when using drag'n'drop: moving/resizing objects. It's completely horrible when I try to move the nodes of a silhouette of somehting.

But well, no one is perfect. Thanks for your work, guys!


By MacBerry at Fri, 2004/10/01 - 5:00am

Great Product!

Need a good comprehensive tutorial based on the version 1.2. The available good tutorial (original one was in french) was based on 1.1 which has changed considerably in functionality and the user interface.

Maybe the original author could redo the tutorial for version 1.2.


By Eric at Thu, 2004/09/30 - 5:00am

That would really be nice indeed.

Fab


By Fabrice Mous at Thu, 2004/09/30 - 5:00am

Got a good one from http://www.bhairon.com/gnulinux.html. Also available from scribus.net. They must have just added it!


By Eric at Thu, 2004/09/30 - 5:00am

Seen http://docs.scribus.net ???? More to come there btw...


By Craig Bradney at Sat, 2004/10/02 - 5:00am

Hi,

Can I use Scribus if I want to create A5 booklets printed on A4 paper, or A4 booklets printed on A3 paper? If my booklet has 48 pages, will page 48 and page 1 (2 and 47, 46 and 3, etc) be printed on two halves of a page? So I can just print it double sided, fold it in half and staple it?

If this works, is it then possible to add a graphic that spans from page 2 to page 3. So half of it is on page 2, the other half is on page 3. Is this taken care of automatically? I don't know if this is a good practice, but one sees it often in magazines and it is rather cool.

Jo


By Jo at Thu, 2004/09/30 - 5:00am

I don't know if scribus supports that, but to me that sounds mor like a job for pstops (a little tool made esp. for things like that)


By furanku at Wed, 2004/10/06 - 5:00am

It's on the Roadmap for 1.3 I think. I don't know if they're going for simple 'build booklet' functionality or more advanced imposition facilities.

You can build simple booklets using Cups and filters - I forget the details but I can explain if you respond to this message. No facility to adjust for creep as far as I could see unfortunately.

Probably lots of other ways of doing this too.


By Joeboy at Wed, 2005/01/12 - 6:00am

I'd really like to see a template/wizard/whatever for making books/booklets in Scribus. I think it's a wee bit odd that a command line program is all that is viable for making these booklets ;)

Keep up the good work scribus.


By Sam Murray at Mon, 2005/11/14 - 6:00am

Many thanks.
I'm using GNOME, not KDE but I'm sure there's a way around that. I'll try to get kprinter installed.
Sam


By Sam Murray at Tue, 2005/11/15 - 6:00am

This hint is for printing double-sided pages on a single-sided printer, not composing a booklet.


By jscarry at Wed, 2006/01/25 - 6:00am

There is a command line package called pdfbook that does this very thing from PDFs. If you don't mind installing latex, I think it's what you're looking for.

http://www.ctan.org/tex-archive/support/pdfbook/

Bovin


By bovin at Thu, 2006/04/20 - 5:00am

Some rumors on a conference in Bordeaux said that some developpers of Scribus managed to reverse-engineer the file format of Quarck express, and thet they have received death letters... Is it true?


By zoobab at Thu, 2004/09/30 - 5:00am

I seriously doubt that (I don't know if it's true or not) but given how friendly Quark reps tend to be, maybe it's not that farfetched. ;-D


By regeya at Fri, 2004/10/01 - 5:00am

For me the question is important how to fund the project. How can an infrastructure be created which assures that the financial supply for development is there.


By Bert at Sun, 2004/10/03 - 5:00am

well, there could be some financial support, but the project has come far without money. as have alot OSS projects. a sponsor whould be great, though.


By superstoned at Mon, 2004/10/04 - 5:00am

two aspects of speed exist when it comes to scribus.

The first: people complain scribus is slow when working on text in frames. True, but here is how you can get even faster speed than with traditional dtp apps. Use the story-edtior. think of it as a high-speed no-nonsense wordprocessor built into scribus. Don't touch text in frames, use this. And use the Properties palette. Fly-by-wire.

The second: remember the venerable pagemaker took almost a decade for an upgrade from version 6 to version 7. quark though much faster, took the traditional 'several years' for an upgrade too. scribus works on an almost daily upgrade. that is how the developers got those 700 bugs and wishlists fixed. i have been watching the development speed of scribus, when it was a squiggling sperm in a petri-dish. Someobody should just do a story on this process, speed, and rapid evolution, where developers and end-users merge into one gooey mess to scratch their personal itches every night.

Quite remarkable.


By linuxlingam at Thu, 2004/10/07 - 5:00am

I'm hoping someday to find a way to get it to work with my workplace's current workflow, and convince my company that this is viable, in that order. I've almost convinced myself to try doing some prepress work through Scribus at work in this coming week (wish me luck!) I've been very impressed by Scribus, particularly its PDF support. I've been using Scribus to set up templates for printing digital photos on my Linux machine, then printing the prints out either here at home on a decent Winprinter or for taking the PDFs to work to print prints on an Epson 1280 Photo. Rock on.

The thing is, the way things are set up now we have a specific list of settings for one particular version of QuarkXPress (4.11, sadly), a particular version of Acrobat (5, sadly) and have gone as far as having a Quark template to use to prepare pages for a particular Konica imagesetter. The main obstacle is that this was all set up by some of our corporate guys, and I have no idea how hard it will be to set this up. Here's the difficulty:

Apparently when we prepare individual pages, it's enough to use EPS. However, then we'll pull two pages into art frames in Quark, then print PostScript to a file using a particular PPD. We then use Distiller to convert this to a PDF using settings mandated by our corporate techies.

Now, I tried a little experiment a while back: I used a PPD intended for a LaserWriter 16/600 instead of the PPD intended for a Konica EV-jetsetter 9xxx-series (I don't work with it, so I don't know the actual model number) imagesetter, and everything went fine and dandy. Not sure if that's enough, but I'm certainly hoping. I just hate to waste (allegedly tight) company resources on an experiment on actual content.

Anyone out there have any experiences working with Scribus in real print shops?


By regeya at Sat, 2004/10/09 - 5:00am