[Scribus] Re: WP vs DTP
Tue Dec 21 00:30:05 CET 2004
On Monday 20 December 2004 22:00, Rainer wrote:
> I agree. Truth is, though, that this (broken) system is all most people
> want. And it will be many, many years before you overturn this WP model.
I don't believe it is all they want. I think it is all they know, and they are
now used to it. You are correct that it would take years for many to migrate,
but just because it might take some years to complete something doesn't mean
we shouldn't start.
And then there are the newcomers, who may one day (quite soon) turn to their
parent or older sibling and ask: "Why do you use that WP thing? I can do all
that you're doing, with much more control, using Scribus."
> I think the proper solution might be a fully functional module--that is,
> turning the current Story Editor in something much grander. This may be
> a hard sell, though. It would mean marrying a WP/DTP-cross module into
> the actual DTP, I would think.
I am happy to discuss the various options that different people see. My view
is to keep the essential DTP workflow (everything is in a frame), and add
enough automation that people coming from a WP background aren't
inconvenienced, but without taking on board any of the WP failings.
I asked a question on this list earlier regarding the separation of the Story
Editor vs the WYSIWIG editor, and didn't get any answer that clearly spelled
out why there needed to be the distinction.
> And then there are spreadsheets, tables,
> etc. When does the list stop?
Somewhere around the 80-20 rule: The 20% of features used 80% of the time.
You are correct about spreadsheets etc. Here is what I've seen by looking at
what Scribus does, and how:
would propose that either any table can support calculating cells, or a
subtype of the table frame is created that supports spreadsheet
I am not proposing a system for modelling global weather patterns. I am
proposing building enough support for formulae etc that a user can build a
grid of calculated cells, connect them with formulae, and package the result
in PDF, thereby providing a read-only spreadsheet that also has provision for
user input - ie a dynamically recalculating spreadsheet in which the formulae
cannot be modified, and which can be viewed and recalculated on any platform
in any modern PDF viewer.
The ability to display basic charts would be important, but these will also be
important in presentations (see below).
If these features are kept within frames, then a final PDF document can be
built that is laid out accurately according to the author's wishes, and which
effectively embeds text, images, calculating fields and grids, forms, etc.
> I would still argue the separation of the
I would argue that the Scribus project currently presents the opportunity to
create a much simpler, single tool that supports the essential 20% of the
features that Office packages do, with a simple, consistent interface;
multi-platform, non-proprietary file and output formats; and a basic model
that isn't broken.
I believe we can find a relatively simple way to leverage that potential
without compromising the DTP abilities of Scribus.
> Not to say a more powerful Story Editor would be a bad thing, but
> let's not divert energies away from Scribus' core DTP development.
I don't want to diminish the growth of Scribus at all, particularly not its
DTP development. I think the "everything in a frame" model is what makes it
so superior to the WP "eveything in the soup" model.
An enhanced story editor is one approach; an extended Scribus project that
builds on and extends the base Scribus code is another solution; extending
existing features to be more general is another solution; adding simple
automation features is yet another.
> Just my humble 1.5c. Drat, .6c after taxes! ;-)
I thank you for your input, as does the Tax Dept :o)
More information about the scribus