incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <>
Subject Re: Header/Footer of Simple API (earlier - Re: Is there a way to extract text on a page basis from odt ?)
Date Wed, 28 Sep 2011 09:00:10 GMT
Am 28.09.2011 03:36, schrieb Devin Han:
> 2011/9/26 Svante Schubert <>
>> Hi Dasiy, Hi Devin,
>> Am 26.09.2011 08:05, schrieb Devin Han:
>> ...
>>>> Daisy or Devin you once implemented the text extraction for the complete
>>>> document, right?
>>>> org.odftoolkit.odfdom.incubator.doc.text.OdfEditableTextExtractor
>>>> Is this as well accessible via the Simple API? I could not find it.
>>>> In this context, when I looked for the extraction functionality, I
>>>> stumpled over the method getFooter()/getHeader().
>>> We supply the following, not thinking as simple as in your mind:
>>>     public Footer getFooter;
>>>     public Footer getFooter(boolean isFirstPage);
>>>     public Header getHeader();
>>>     public Header getHeader(boolean isFirstPage);
>> You offer those methods on the test document. Do you believe, you cover
>> full ODF 1.2 header/footer functionality?
>> If not what do you think is missing. (for hint see blow)..
> Something is better than no action. Most of time there is only one
> header/footer, or the first page are different. It's just a start and we
> need to collect the feedback from user. If necessary, we will continue work
> on it. If you are interested in this feature, you can dive in it.  I would
> be like to discuss it with you.
> BTW: I think this issue should be post in, not
> here. To complex discussion will make the user lost, especially for the
> freshmen ;)
You are right, I switched the mailing list from user to dev now.

In general whenever we create a new ODF feature, we should have the
overall solution in mind. This would allow us to provide a design that
covers all scenarios. We still should focus afterwards on the most
demanding (20/80 rule).
Otherwise, if we keep it too simple and focus on the design of the
smallest most important use-case, the design will be broken as soon as
new ODF scenarios are being added. This would result in patch work,
higher development cost in the end and API changes for the users. None
of that is desired by anyone. Right?

Regarding the header/footer some background information first for the
rest of the list.
Header & footer and all its content is written in the styles.xml file.
Their content is the only content that is not in the content.xml and the
reason why automatic styles (styles without name access) might occur in
the styles.xml (when being used on a header / footer). A header / footer
might contain any ODF content, even complete arbitrary documents, there
is only one thing forbidden in header/footer: page-breaks.

Each header & footer is defined in a master page, see

As explained by the reference above, any paragraph or table of a
text/spreadsheet document might use a different page styles with
different header/footer by using the attribute style:master-page-name in
its style.
Undocumented is that OOo and its clones use the header/footer of the
"Standard" style by default.

To solve offer a long-term solution for header/footer, we need to create
a test document with varying footer/header in paragraphs & tables first
(see test driven development).

If we analyze and abstract the problem:
>From a high level view on the document, the sequence of the document
might have several starting points of new master page (and their
header/footers), resulting into sub-sequences of used master pages.
It would be reasonable to be able to provide arbitrary component to a
function and return the used master page, or return the sequences.

I plan to cover sequences in my upcoming change-tracking proposal for
ODF. (see and
references within).

Suggest we deprecate the existing functionality as soon we have the new
consistent one and paste the above in a new issues for enhancement.

- Svante

>>> You return those from the document without a context. But there might be
>>>> multiple header/footer in a document.
>>>> One pair for each master page style, therefore you need a context or
>>>> your simplification is only a good guess, but sometimes wrong.
>> - Svante

View raw message