[scribus-dev] Scribus 1.4
gpittman at iglou.com
Tue May 27 22:28:01 CEST 2008
Louis Desjardins wrote:
> 2008/5/18 "Christoph Schäfer" <christoph-schaefer at gmx.de
> <mailto:christoph-schaefer at gmx.de>>:
Without adding to an already rather large email/commentary, I wanted to
make a few observations.
One of the things we face is that 1.3.5+ represents a major jump in its
underpinnings (qt4/cairo), so at some point this chasm must be jumped. I
don't know that the naming of 1.4 vs 1.3.5 is such a critical one, but
certainly these multiple digit versions, like 1.3.3.x have been
confusing to many. Do we really think that 1.3.5 vs 1.4 has such a deep
As Louis alludes to, I think we must focus on the Scribus core features,
the features professional layout people and professional printers
require. Thus we cannot simply keep a score of numbers of times various
features have been requested, but must apply some kind of weighting
based on who is making these requests, that is, if Scribus is truly
aiming to be a professional layout app. The pros seem to want improved
text handling, better imaging handling (including color management), and
better utilization of vector drawings of various types. These also
require better memory management and scalability, hopefully improving
speed if nothing else. Once the core features of 1.3.5 are usable with
good predictability, it is ready for release.
In some respects Scripter is not a core feature, yet as we move to 1.3.5
and beyond, the original is completely broken, so I don't think
scripter-ng should be abandoned.
Even as someone heavily involved with the manual, I don't think we can
let manual issues interfere with Scribus development.
The next generation manual is going to take perhaps as long or longer to
create, plus some parts can't be finalized until various features reach
some reasonably complete state. The original manual should still be very
much usable for 1.3.5 and beyond, even with mismatches of screenshots.
Scribus has developed quite a following with no comprehensive official
manual at all.
I don't think that the project should necessarily stop some seemingly
peripheral plugins that may not be core features, since there is a
certain energy that comes from these that may suggest new ways of
dealing with core feature problems.
More information about the scribus-dev