OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Page-based layouts in word processing documents

Hi all,

I am looking at how to define a page-based layout based on <draw:page>, but with
all the Word Processing features, to model KWord's DTP documents.

First, I see a strange comment in the OOo file format description, p84 (2.6, Frames) :
it says there that text boxes are for OOWriter docs only. Doesn't one need text boxes
in presentations (i.e. in OOImpress) as well?
If text boxes are indeed meant to be used in presentations: is it ok to use the 'chaining'
feature for them?

Is it correct to say that headers/footers are supported just fine in <draw:page>,
since it can refer to a master page?
What about footnotes/endnotes? 
Presentations seem to have their own kind of notes ("presentation notes", 5.1.2 p328).
In the footnote/endnote unification we talked about "other kind of notes" - is that
one that can fit into this scheme? They are not text-only notes though, they can contain
any kind of shape (text is done with a <draw:text>). It's not really specified how/where 
they appear, which makes sense for a presentation program (they'll be out of the document
itself), which differs from what happens in a word-processing document. I think this in
fact rules out merging presentation notes with footnotes/endnotes?

Another thing that is missing from presentation programs (like OOImpress) is tables.
(Insert / Table inserts an embedded spreadsheet).

The main problem I see with using <draw:page> and no main text flow as the way
to represent DTP documents in KWord, while still using e.g. footnotes/endnotes/tables
is that this won't map to any OO application. This is where issues of document 
conversion come up again, although being all based on the same file format...

However there's no solution to that, different concepts can't always be 
represented the same way. For "word processing" documents, no problem,
but for DTP documents (no main text flow) such docs would be unusable out of 
KWord, unless either
1) OO is changed to let OOWriter parse documents based on <draw:page>,
by creating a main text flow with nothing in it except page breaks, and by applying
the page layouts from the <draw:page> elements.
2) KWord actually saves things that way, i.e. not using <draw:page>, but generating
the main text flow with the page breaks when saving, and ignoring it when loading
(based on some "this is DTP" flag, hmm that would be a KWord-specific attribute somewhere).
I guess this approach is simpler, more compatible, and makes all existing 
conversion filters work.

David FAURE, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]