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 Fri, 30 Sep 2011 08:01:30 GMT
On 30.09.2011 09:58, Devin Han wrote:
> Hi,
> 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!
Sure it would be great, but I am already volunteering for ODF TC work
next month.
> 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.
+1 as equal to what I said before:

"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

> 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,
>>>>>> 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
>>>>>> your simplification is only a good guess, but sometimes wrong.
>>>> - Svante

View raw message