[scribus-dev] Scribus 1.4

[Gregory Pittman]

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 
philosophical meaning?

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.

Greg