[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]