[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:       Thomas Diehl <thd () kde ! org>
Date:       2002-12-02 13:19:28
[Download RAW message or body]

Am Montag, 2. Dezember 2002 13:09 schrieb David Faure:

> 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".

Well, if I have a similar case in Ventura (eg 12 identical business cards for 
printing on an A4 page) I define a custom page the size of one business card 
and tell the printing dialog to get me 12 of them on the film or paper. (The 
advantage is: I can work as usual, no need to re-learn anything and to adjust 
myself to a different program mode. If need be I can also get automatic crop 
marks on the edges of my user defined page if a printer shop wants to know 
where to cut the paper -- no need to draw those crop marks manually.)

> 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".

Well, it would be nice if the empty paragraph could be removed. ;-) 
(In Ventura, only clicking into a frame and starting to type results in 
creating a text file. You can always completely remove this.)

> This is the main problem - especially since new frames default to the
> "text should run around me" setting.

...which is fine but can be changed to "run through frame" by the layouter. It 
may even make sense to change the default mode of the standard frame to 
"run through frame" for a template/style sheet that is meant for graphics 
intensive stuff (as I routinely do as you can see in the Tag Window of  
http://www.dtp-service.com/ventura/ventura_navigator.png).

> 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".

Sounds great. ;-)

> Code such as "don't lower a frame under the main frameset"
> would always be activated.

Not sure if we mean the same thing here. Anyway here goes: There _can_ be 
reasons that users (at least DTPers) may want to have a frame under/behind 
the base page, even bigger than the base page. At least in Ventura, this is 
used to create "bleeds".

For instance: I want a background graphic, watermark effect or a fill printed 
to the paper border with no white streaks anywhere. I often can not achieve 
such a complete fill by just filling the base page because this will often 
result in white streaks in the border area. To avoid such streaks I have to 
go beyond the borders and make the fill (graphic, watermark) "bleed off" the 
page and cut the paper afterwards. This is normally achieved by putting a 
frame behind the base page, make the "frame behind" slightly bigger than the 
base page and turn crop marks on to let the book binder know where (s)he has 
to cut the paper. Result: no white streaks in the page border area.

Maybe not an everyday use. But DTPers _do_ need something like this all the 
time.

> Same for the automated frame layouting:
> even in "page layout" mode it would still take care of resizing the frames
> of the main textframeset.

Hmm, I probably have not used KWord enough to understand what this automatic 
resizing means. If it only pertains to headers, footers, footnote frames I 
don't see a big problem (yet). But it shouldn't interfere with user drawn 
frames. I certainly wouldn't want the program to automatically change the 
size or position of anything I actively brought into the layout.

> 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

Don't see a big problem with that (yet).

> 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...

Well, from a user point of view it would make no difference if the paragraph 
was removed or just hidden. But I guess most people will expect that they can 
type in the base frame if they want to, be it that there's kind of a switch 
to lock/unlock the page for typing (hide/unhide that paragraph). Personally I 
would probably be fine with just take care of the paragraph myself and change 
the default for user drawn frames to "text runs through", if possible.

Sorry, if I can't go into any more details. Much as I'd love to, I have KWord 
not yet used enough for this. (Maybe I should post a message on occasion what 
features would be required in order to write my next KDE book or possibly a 
KOffice book in KWord? ;-)

Regards,

Thomas

-- 
KDE translation: http://i18n.kde.org
Deutsche KDE-Uebersetzung: http://i18n.kde.org/teams/de
_______________________________________________
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]