From odf-dev-return-259-apmail-incubator-odf-dev-archive=incubator.apache.org@incubator.apache.org Wed Sep 28 09:00:39 2011 Return-Path: X-Original-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 94EC97944 for ; Wed, 28 Sep 2011 09:00:39 +0000 (UTC) Received: (qmail 58343 invoked by uid 500); 28 Sep 2011 09:00:39 -0000 Delivered-To: apmail-incubator-odf-dev-archive@incubator.apache.org Received: (qmail 58284 invoked by uid 500); 28 Sep 2011 09:00:39 -0000 Mailing-List: contact odf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: odf-dev@incubator.apache.org Delivered-To: mailing list odf-dev@incubator.apache.org Received: (qmail 58275 invoked by uid 99); 28 Sep 2011 09:00:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Sep 2011 09:00:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of svante.schubert@gmail.com designates 209.85.215.175 as permitted sender) Received: from [209.85.215.175] (HELO mail-ey0-f175.google.com) (209.85.215.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Sep 2011 09:00:33 +0000 Received: by eya25 with SMTP id 25so5960962eya.6 for ; Wed, 28 Sep 2011 02:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KHTHaLXK6obha/OER45qh9bn0TyaAc0e4Gl1gV0mnqg=; b=UYYqCkuHjuhbf1eDruo1UHJ/o6NQx6LcayumfxmnCzBfUc/eIdo8CV27Z37ASw2qbx ZAis25gJn2uny0PP3sA/IU9RPyNdqfiERJ9yVsfyPhklcYs5eq9X9KGIQdK3WxS4DhdF K6eGT+QNzj3iZnax+sJsMYLF7PM0faouL6kFg= Received: by 10.14.5.209 with SMTP id 57mr989548eel.178.1317200411416; Wed, 28 Sep 2011 02:00:11 -0700 (PDT) Received: from [192.168.2.100] (p5B0CBDA8.dip.t-dialin.net. [91.12.189.168]) by mx.google.com with ESMTPS id f16sm39180323eec.8.2011.09.28.02.00.09 (version=SSLv3 cipher=OTHER); Wed, 28 Sep 2011 02:00:10 -0700 (PDT) Message-ID: <4E82E21A.7080001@gmail.com> Date: Wed, 28 Sep 2011 11:00:10 +0200 From: Svante Schubert User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: odf-dev@incubator.apache.org Subject: Re: Header/Footer of Simple API (earlier - Re: Is there a way to extract text on a page basis from odt ?) References: <4E7EDEFF.3060909@gmail.com> <4E80485F.2040601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 odf-dev@incubator.apache.org, 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 http://docs.oasis-open.org/office/v1.2/cos01/OpenDocument-v1.2-cos01-part1.html#__RefHeading__1416290_253892949 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 http://lists.oasis-open.org/archives/office/201109/msg00025.html 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 >> > >