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: Proposal: Page Sequences

Hi all,

I have the action item to suggest a method for page sequences. I 
understand the requirements derived from KWord to be:
1) There can be arbitrary sequences of pages and page layouts.
E.g., pages could alternate between landscape and portrait, or each page 
can be 1cm wider than the previous. There can also be empty pages 
without any text flow on them.
2) Text frames can be anchored arbitrarily to pages.
3) There is no main text flow; in particular, no pages are generated to 
make space for the main text flow.
4) The format should be similar to the existing documents, so that such 
documents can be read reasonably well by other word processors, too.

Current state:
These requirements can be mostly emulated in the OOo base format. Item 
2) is covered by frames anchored to pages. An empty main text flow (item 
3) is allowed by the spec. There's no direct solution for item 1), 
although it can be emulated by either creating one paragraph per page 
and assigning each a page-break that uses a new master-page, or by 
creating one master-page for each page and linking them through the 
next-style-name feature. Both emulations would result in mostly similar 
appearance, but different behaviour.

A better solution would be to change the spec to
1) explicitly mention this use-case,
2) introduce a page sequence element, that solves item 3) properly.
If those are the only changes, item 4) would be fulfilled as well. 
Applications that don't know about page-sequence would ignore them. 
Applications should at least preserve the page-sequence, even if they 
don't interpret them.

Basically, what I suggest we do is to add an optional element 
<text:page-sequence> that is allowed in the beginning of text documents. 
This element contains a sequence of <text:page> elements, each of which 
has a text:style-name attribute which references a master page. The 
semantics are that the document contains (at least) as many pages as the 
<page-sequence> contains <page> elements, with these pages being 
formatted as described in the corresponding master page. If there are 
more pages than page elements, the remaining pages are formatted as 
usual. If (e.g. through page-breaks -with-new-master-page in the main 
text flow) other page formatting occurs, the page sequence takes precedence.

As a result, a 'DTP' type document could look as follows:
(It contains a limerick, with one line per page, placed differently on 
each page, and the page formats matching the rhyme scheme.)
  <style:page-master name="pm1"> <!-- portrait page --> </style:page-master>
  <style:page-master name="pm2"> <!-- landscape page --> 
  <style:page-master name="portrait" style:page-master-name="pm1"/>
  <style:page-master name="landscape" style:page-master-name="pm2"/>
    <text:page text:style-name="portrait"/>
    <text:page text:style-name="portrait"/>
    <text:page text:style-name="landscape"/>
    <text:page text:style-name="landscape"/>
    <text:page text:style-name="portrait"/>
  <draw:text-box text:anchor-type="page" text:anchor-page-number="1" 
svg:x="1cm" svg:y="1cm">
    <text:p>There once was a lady from Riga</text:p>
  <draw:text-box text:anchor-type="page" text:anchor-page-number="2" 
svg:x="2cm" svg:y="2cm">
    <text:p>Who went for a ride on a tiger</text:p>
  <draw:text-box text:anchor-type="page" text:anchor-page-number="3" 
svg:x="3cm" svg:y="3cm">
    <text:p>They came back from the ride</text:p>
  <draw:text-box text:anchor-type="page" text:anchor-page-number="4" 
svg:x="4cm" svg:y="4cm">
    <text:p>With the lady inside</text:p>
  <draw:text-box text:anchor-type="page" text:anchor-page-number="5" 
svg:x="5cm" svg:y="5cm">
    <text:p>And a smile on the face of the tiger.</text:p>

There's two things I wasn't sure how to do, so maybe one of the 
following variants might be better:

Alternative 1: have <page> elements refer to master-page (instead of 

The page-master may also contain headers and footers, while the 
master-page (now renamed to page-layout) contains only the page layout, 
e.g. dimensions. I think it would suffice for the requirements to 
directly refer to master-pages. However, so far we've always used the 
page-master for page formatting, and referred to master-pages only from 
the page-master. Also, headers/footers might have funny interactions 
with page sequences, if page-sequence would refer to master-pages.

(After having written that, I'm so glad we renamed the master-pages to 
something sensible. When casually reading, the above doesn't seem to 
make any sense...)

Alternative 2: put the page-sequence into the styles section.

The page sequence is pure styling, so it would make more sense to put 
this into the styles section. If one were to do that, the styles section 
would have the page sequence appended, and the application would have to 
apply the page sequence whenever it finds one.
However, so far styling information is mostly referenced from the 
content, and not active by itself. In this case, the page-sequence 
provides this referencing. (With, admittedly, some exceptions: E.g. line 
numbers of some of the 'special' styles are automatically active, sort of.)


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