Re: [office-accessibility] Q: ODF 1.1, Soft Page Breaks

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

Dave,

please see my comments inline...

Malte.

Dave Pawson wrote, On 08/11/06 13:31:
> Hi Malte.
>
> On 11/08/06, Malte Timmermann <Malte.Timmermann@sun.com> wrote:
>   
>> I have some question and annotations to Soft Page Breaks.
>>     
>
>   
>> 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...
>>     
>
> For Daisy, I am only interested in the XML I get from an ODF file,
> so the 'export soft page breaks' interpretation is good for me.
>
>   
Fine, "export of" is also my interpretation, so I will send this as
editorial change.
>
>
>   
>> --------------------------------------------
>>
>> 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.
>>     
> (from memory) I think I do process some style information.
>
> soft-page-breaks are document content related though?
> Perhaps it is right to  call it metadata or style information,
> but surely there must be *something* in the XML document content?
> The semantic is 'there is a soft page break here'.
>
>
>   
I think you are mixing soft/hard breaks.
I just wanted to point out: With our specification, only hints for soft
breaks can be found in the content directly.
The information about hard breaks comes from styles.
But seems you are processing them anyway...
>   
>> 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.
>>     
> Daisy itself does not have a page based model. (It is generally either the
> same as HTML on screen, i.e. scrollable, or audio, again a stream.
> The page breaks are taken as being a reference to the original source
> document, informing the reader where the breaks were in that document.
>
>
>
>
>   
>> 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.
>>     
>
> Does it make sense that daisy is not a paginated media?
> Think of an audio book. The audio doesn't have pages, but the print
> book on which the audio is based is paginated. Different things?
>
>   
IMHO the reason for pages in DAISY books is to have them for references
and as an additional level of navigation.
>
>   
>> 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?
>>     
>
> A bit of a guess on my part, but when I set up OOo, I say I'm using A4 paper,
> possibly set margins and headers, footers for a document.
> That effectively defines how I want the pagination?
> Or am I misunderstanding something?
>
>   
Maybe I was confusing you: You are right, there is currently only that
one layout and you are influencing it with page size and so on.
But that's only the implementation in OOo. Other apps might offer
displaying the same content with different layout in different views.
One View could render the content in an "horizontal Letter" print
layout, while the other view renders in a "vertical large print A4"
Layout, in the same time.
>
>   
>> 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.
>>     
>
> Yes, I am OK with that. Conversion to daisy format will be
> a one off occurrence for a document.
>
>   
Yes, but it's not so nice that it must be stored in a special way before
doing the conversion...
Same category like "tagged PDF should be the default", which is not the
case because of file size.
But everything that is optional will not be used in most of the documents.
>
>   
>> 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.
>>     
> Surely they will need to be linked?
> E.g. to identify the point in the document at which the layout specification
> has resulted in a new page?
>   
Yes, the layout is just the layout, and links to the content coming from
content.xml.
>
>   
>> 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....
>>     
>
>
> I can see layout.xml being a specification of how a document should
> be laid out, but not the *only* place to go looking for page breaks?
> Again, I may be misunderstanding something.
>   
If we had a separate layout stream, that would be the only place to get
information about *soft* page breaks, because soft page breaks are
layout, not content.
But we don't plan to do that right now, I just mentioned it for
completeness.