Re: [office] Page-based layouts in word processing documents

[Michael Brauer <michael.brauer@sun.com>]

Hi,

David Faure wrote:
> 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?

The comment is wrong. Text boxes an of course appear in draw pages as well.

> If text boxes are indeed meant to be used in presentations: is it ok to use the 'chaining'
> feature for them?

I think yes. The file format should support chaining for text boxes 
contained in draw pages, but it will probably not be supported by 
typical presentation apps.

> 
> Is it correct to say that headers/footers are supported just fine in <draw:page>,
> since it can refer to a master page?

Yes, I think so.

> What about footnotes/endnotes? 

- The footnote configuration is a special style. The file format 
supports it for all apps.
- How much space footnotes can occupy on a page is specified in the 
<page-layout> element, so this is suuported by all apps as well.
- The footnotes themeselves are contained in paragraphs, that again are 
supported by all apps.

This means that file format supports footnotes for all applications, but 
currently only word processers will make use of them.

BTW: I've noticed that the OOo specification document mentiones a 
<footnote-layout> element, but the DTD does not. The specification 
document is wrong here. All footnote specific attributes and elements 
are contained in the <properties> element of the <page-layout> (or 
former <page-master>) element directly.

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

There is a special view that makes presentation notes visible. The 
presentation notes are drawing objects that the presenter can print out 
together with a preview of the slides, but that do not appear on the 
slides directly. They in fact seem to have little in common with foot- 
and endnotes.

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

OOo Impress in fact does not support tables within text boxes, but the 
file format does.

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

A "DTP" flag could be one solution, a document class of its own another 
one. I don't have any idea what is the better choice at the moment, but 
I think we should add one of these two options to the specification.

Michael