incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devin Han <>
Subject Re: Header/Footer of Simple API (earlier - Re: Is there a way to extract text on a page basis from odt ?)
Date Fri, 30 Sep 2011 07:58:08 GMT

You can create an issue to trace the process. As you have submitted a
concern proposal, so if you can volunteer to do it, that will be great!

If you are interested in it, please do it. But before the new design is
implemented, I don't agree to deprecate any the existing functionality about
header/footer. I know lots of users have applied this feature in their
applications, there is no reason to deprecate it, before a new one.

2011/9/28 Svante Schubert <>

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message