Hi, I'm skipping the Word Processing vs. DTP part now, because I find your arguments valid on the basis of how word processors work and how DTP programs work. In the end, the more realistic focus i'm having is strengthen the DTP like parts in Writer and strengthen the style metaphor.
> That would be interesting. And it has applications. Something like a CMS, > except for documents instead of just web pages. I like the idea, and would > be interested in using it, if it existed. But I think that probably, the > vast majority of people (and I'm basis this on usage statistics) want > WYSIWYG. Word is far more popular than LaTex. I didn't say you couldn't i wouldn't wanna do that in a WYSYWYG manner. > In other words, it would force the user to apply >> styles to everything. But it would also help the user in doing that, it >> would automatically suggest styles (i.e. based on the previous/next >> style) settings in the styles themselves. > > Forcing users is bad. No means no. Ok, it's obviously bad to use words like "forcing". Makes you go defense mode just by reading it. How about "translating" or "suggesting"? What I'm thinking of has basically been done in this or that way already, just not consequently enough. I.e. MS-Word automatically internally creates a new style for every different formatting. That's basically all we need, together with OOo's ability to have page, image and frame styles. Now all we need is replace things like "bold", "italic" and so on with semantic formatting options like "strong", "emphasis" etc. . And provide default "strong" and "emphasis" styles that are i.e. bold and italic. Add a bit of non-interrupting UI that suggests styles to the user. Styles here means it suggests semantic attributes like "Is this a heading?" - "Yes" "No"...or similarly (this example is in fact too simplistic). This way the user is forced (without feeling restrained at all) to use semantic formatting instead of optical and once you are that far it's pretty easy to provide capability to introduce templates (aka stylesheets) that the user can't violate through individual formatting. Yes, this is in a way a restriction for the user, but it is a choosable restriction - as soon as he uses the template, he can't violate the template, if he wants to do different stuff, he can start from scratch and create his own styles. I strongly believe that this kind of restriction actually empowers authors in business offices who don't want to bother about layout but would still be able to create layouted documents that pratically layout themselves as they type the content. > That's good to know from a techie standpoint - but that doesn't matter at > all to the end user. That may explain why the problem exists - but it does > nothing to fix it or make it better. Maybe we should write an office suite > in XUL. Look at what projects like SongBird - > http://www.songbirdnest.com/- and Flock - > http://www.flock.com/ - are doing with it. Of course that changes nothing. But it's where we are. The problem is that these cross-platform approaches are indeed not cross-platform approaches. They introduce their own platforms that themselves are cross-platform, but now the new cross-platform challenge isn't about Windows, MacOS and Linux anymore, but rather about XUL, GTK and OOo Bridge. ;-) So what do we do? Decide for one of them? Then which is the best, really? Perhaps we can create another cross-platform environment? ;-) > Your "discrediting" of my point about why a sutie should be a suite and not > just some random collection of programs - you seem to think that all > programs in the world should use the same format (so they can pull from the > same database of contacts, for example) that's great, and in a perfect > world, I'm sure they would. But they don't. And they won't. Not ever. > But all OpenOffice.org programs can open the same ODF formats. So > having an > OpenOffice.org email client / PIM / calendar / browser / project manager / > diagrammer / DTP / whatever - they would all pull from the same document > types. We can't make every other program open our database files. We > can't > even make every other open source program open our database files. What we > can do is make a program that does. What do we need ODF for, then? It's all about creating inter-program-suite standards, so that different programs actually can interact. Furthermore, database access is more or less standardized. All you need is a standard address database format. And it doesn't need to be supported by all applications, it just needs to be an agreement of Mozilla and OOo for a start. > Here's another reason for an email client to be a part of the same suite as > an HTML editor and the same suite as a word processor and the same as a > DTP... Shared libraries.... I agree, but I'd say your approach isn't quite the right one. What you want is a propriatery approach...provide everything from one vendor and you will have no interchange problems and no redundancies. But the better solution is to establish standards and have people go with those standards. The "cross-platform platforms dilemma" is a big issue here, and i wonder if it's ever gonna be solved. However, there are approaches to standardize things between different productivity applications, like the Tango project, the FreeDesktop project and the Create project. André. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
