No subject
Tue Dec 12 00:08:36 CET 2006
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 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 with 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; software
developer
* Jean Ghali (further as JG) - is responsible for the Windows
native 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 -
beginner to pros.
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
[http://wiki.scribus.net/index.php/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 [http://rants.scribus.net/]
you provided [http://rants.scribus.net/2006/07/12/yay-gotcha-4000/] 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 quick 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 [http://lib2geom.sourceforge.net/] 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
[http://quanta.kdewebdev.org/], 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 [http://dtpblender.instinctive.de/] 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 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?
[http://create.freedesktop.org/wiki/index.php/Open_Color_Standard]
PL: This is somewhat of a red herring. Spot colours are used less
often than one might be thought. 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
[http://www.freedesktop.org/wiki/Software_2fHarfBuzz] 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
[http://www.apple.com/macosx/features/colorsync/] on OS X and ArgyllCMS
[http://www.argyllcms.com/] 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.
More information about the dot-stories
mailing list