Q: ODF 1.1, Soft Page Breaks

[Malte Timmermann <Malte.Timmermann@Sun.COM>]

I am just working on the details how/when to implement which ODF 1.1
Accessibility features in OOo.

I have some question and annotations to Soft Page Breaks.

More below,
Malte.

--------------------------------------------

Clarifications, Editorial Changes:

Section "Use Soft Page Breaks":
An application that computes a paginated layout of a document should
provide a facility to turn on soft page breaks for the purposes of
consistent page breaks and for proper conversion to digital talking book
formats (such as [DAISY]).

What do we want to say here:
- turn on *export of* soft page breaks
      or
- turn on *using exported soft page breaks for pagination*
It can't be both. ODF Apps can much easier export them than using them
for layout.
I assume we talk about export here...

--------------------------------------------

Processing of <text:soft-page-break>

The name is *soft*-page-break, so it means it will only be used for soft
page breaks, not for hard page breaks.
So there is no page break indicator for hard breaks in the content
directly, that information comes from a style sheet or from an automatic
style.
So the DAISY converter must look into style information to check for
hard page breaks.
But that should be OK, because styles must be processed anyway.
Just wanted to point out this.


An other thing: You should be aware that very likely this feature will
only ease the export to DAISY for the reason that the converter doesn't
have to do some pagination.
But it's IMHO unlikely the ODF applications will use the exported soft
page breaks for pagination in the near future, because that is a very
complicated feature.
So when people want to talk about "Page XY", the author of the document
should provide PDF and ODF with exported soft page breaks for DAISY
conversion, but for reading people will have to use DAISY and PDF,
because ODF will still not be the same on different platforms.


Which Layout to use?
An application might create different views with different layouts for
displaying one ODF.
This is (currently) not the case with OOo, but might lead to problems in
the future: Which pagination will be used when storing the document?


Performance
As you can imagine, storing the document content is completely
independent from the layout.
That means OOo currently doesn't have the layout information when
storing the different content elements.
Of course that can be changed, but that will have some influence on
performance, which is already bad enough.
So storing pagination information in OOo will become an option, the
default will be not to store that information.
Authors should be aware of this.


Layout/View
Just for completeness: The really correct solution would be to have a
layout.xml instead of having soft pages breaks, which means layout
information,  in content.xml.
Content and Layout should be strictly separated.
Layout.xml would contain all page breaks and might contain more fine
granular information like line breaks, portions, char positions and more.
But that's only the theory, for practical reasons we have soft pages
breaks in content.xml now....