[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-12-02 12:09:27
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 02 December 2002 11:10, Thomas Diehl wrote:
> No, sorry. If I create an envelope in any other program than KWord I will just 
> set the page size to fit the envelope size or manually create a frame on a 
> page.

I'm talking about the case where you can print 4 things from the same page.
Ok, maybe envelopes was a bad example then, but let's take the case I
had the other day again: I printed 4 small paper ads per A4 page.
In such a case of page layout, there are 4 text framesets per page, all "equal",
no more "main textframeset". But see below...

> As for labels, I understand this even less. Why would I want to get rid of the 
> base page there? I think the normal user expectation would be to import eg 
> 500 addresses from a database and see them on several dozen pages which show 
> the same margins, gaps, and columns as the label sheets in the user's laser 
> printer. Even if I would use one frame per address (because I'd like to waste 
> the whole day on this ;-) it would be very helpful to see page margins and 
> columns to adjust the labels to (esp. if these margins and columns are 
> "magnetic" and the label frames would snap to them).
Ok, I see your point about page margins. However page margins are just 4 lines,
they do not mean a box in which you can type text. See my previous explanation
about "where does the empty paragraph in the main textframeset go, if the 
mainframeset is totally covered by frames".
This is the main problem - especially since new frames default to the
"text should run around me" setting.

Other than this one, I am now partly convinced about your point. 

- From the start, KWord developers thought that the notion of a 
"main text frameset" was a kind of "hack" that should only be used 
in the word-processing mode, and that for page-layout documents 
we didn't want it at all.
But you're saying it's fine to keep it. 
In that case it's indeed easier to "merge the two modes". 
Code such as "don't lower a frame under the main frameset"
would always be activated. Same for the automated frame layouting:
even in "page layout" mode it would still take care of resizing the frames
of the main textframeset. The code for "insert new page" would always
insert a frame break in the main textframeset - although that's the kind
of thing that looks a bit weird from a user point of view, if you don't
use the maintextframeset at all, IMHO. It's necessary however,
otherwise the code that "automatically removes empty pages from
the end", would immediately remove it - we need that code, for the standard
"word processing" case where people want pages to be automatically
added/removed :)

Ok - on the whole I like this (less modes = less headaches for us ;).
But the main problem remains. Somehow we must find a way (an option?)
to "not layout the initial empty paragraph"? This would mean, however, 
that it becomes invisible (under the frames), and that there's no way 
anymore to type text into the main textframeset. This is where the notion
of two "modes" appears again... Either you want text in the main textframeset,
or you don't...

> If the user actually does not want to have any text in base pages or to 
> automatically add new pages when importing text it would be enough, IMO, to 
> have some sort of "disable base page" or "unchain base pages" feature or a 
> "lock" analogous to the "don't automatically add new frames" feature we 
> already have (AFAIK, can't check at the moment).

Then what will happen when the user creates a new page? This one will not
get a frame from the main textframeset at all? What if the user then starts 
typing text into the main textframeset? Where will it overflow to?
Mixing all this leads to many complex cases to take care of, and this is why, 
for a simpler implementation of many things, the app currently knows about 
those two modes.

- -- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9601372KcVAmwbhARAjWGAJoD+QZHu6OiJATwDyMJtfj9t4MKngCfXn98
Uh0nhP0in2wBuUPI/HUXqhA=
=1M71
-----END PGP SIGNATURE-----

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]