[Scribus] Re: WP vs DTP

[Nik]

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:

Spreadsheets:  Can be supported in PDF output, using fields and javascript. I 
would propose that either any table can support calculating cells, or a 
subtype of the table frame is created that supports spreadsheet 
functionality.

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.

Presentations: Already supported using PDF and javascript.

> I would still argue the separation of the
> two. 

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)

Cheers!
Nik.