Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: pass (nike.apache.org: domain of cav@uniscope.jp designates
 211.9.48.121 as permitted sender)
Message-ID: <4E7A9419.6070504@uniscope.jp>
Date: Thu, 22 Sep 2011 10:49:13 +0900
From: Carlos Villegas <cav@uniscope.jp>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: fop-dev@xmlgraphics.apache.org
Subject: Re: omit first table header/last footer
References: <4AC035C2.9060002@uniscope.jp> <4AC0942B.4010101@gmail.com>
 <4AC0CA8F.1070802@uniscope.jp> <4AF7DE2B.9070803@uniscope.jp>
 <32503728.post@talk.nabble.com>
In-Reply-To: <32503728.post@talk.nabble.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

It probably behaves that way. I wasn't sure about the implementation. It 
was enough for my purposes so I didn't checked it further.

Cheers

On 9/21/11 6:16 PM, champagne_chary wrote:
> Would I be right in assuming that this method removes the header however
> places a space at the bottom of the page. This is unfortunately what i am
> finding. :(...  The space at the bottom of the parent object (be it a  page/
> table row) is  equivelent in height to that the header / more specifically
> the text within.
>
> I have tried to implement in a couple of ways and this phenominum keeps
> occuring. Hope somebody that uses this nifty mod can enlighten me on if
> there is a way around this.
>
> Cheers
>
>
>
>
>
>
> Carlos Villegas wrote:
>> I implemented this extension. I added fox:table-omit-last-footer and
>> fox:table-omit-first-header attributes to fo:table. It seems to work
>> well in my use case.
>> If anyone is interested I can submit a patch.
>>
>> Cheers,
>> Carlos
>>
>> Carlos Villegas wrote:
>>> Thanks for the pointers. I agree that implementing retrieve-table-marker
>>> is not only a more generic solution but also what the spec requires.
>>> However, I'm short on time and this seems easier so I'll give it a try
>>> first.
>>>
>>> Regards,
>>> Carlos
>>>
>>> Vincent Hennebert wrote:
>>>> Hi Carlos,
>>>>
>>>> Carlos Villegas wrote:
>>>>> Hi,
>>>>>
>>>>> I searched the mailing lists and it seems that although some people had
>>>>> worked at several times at trying to implement retrieve-table-marker,
>>>>> it's not yet done. Is somebody working on this? What's the status?
>>>> It’s not being worked on at the moment. This is still a missing feature.
>>>>
>>>>
>>>>> In many use cases omitting the first table header and the last table
>>>>> footer will do the trick.
>>>>>
>>>>> How easy is this to implement?
>>>>> What will be the steps to add such an extension to FOP?
>>>>> I just started looking at the code so I'm exploring whether this is
>>>>> viable solution.
>>>> That might work. You would need to change the
>>>> o.a.f.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements
>>>> method. There is a “if (getTableLM().getTable().omitHeaderAtBreak())”
>>>> test that you could augment with a “&&  !(omitFirstHeader)” clause.
>>>> Likewise for the footer.
>>>>
>>>> The easiest is to directly modify that class and re-build FOP. A bit
>>>> less easy would be to add a variable in the configuration file, so that
>>>> you can enable it only for certain FO files. Even less easy would be to
>>>> add an extension property to fo:table so that you can enable it only for
>>>> some tables of an FO document. Please ask if you need more details.
>>>>
>>>> All that said, such a change would be very hacky and, unless there is
>>>> overwhelming demand from the user community, I would oppose to integrate
>>>> it in the code base. This is a patch that you would have to maintain on
>>>> your side. Better would be of course to actually implement
>>>> retrieve-table-marker. Although this would be more involving than
>>>> implementing this little trick...
>>>>
>>>>
>>>> HTH,
>>>> Vincent
>>>>
>>>
>>