David Tolpin wrote:
>> I don't see why implementing table markers is any more difficult than
>> implementing regular markers. Perhaps its down to the fact that
>> regular marker content is always retrieved outside of the flow, where
>> as table markers will be retrieved inside the flow. Which I guess
>> would affect page break possibilities.
>
>
> Because table markers change the size of the table's header after the
> header is measured. And after the header is modified, the marker's
> anchor may have to go to the next page; this is similar to, but more
> complex than, footnotes due to interaction with floats.
Well, can't you measure the header after the marker content is retrieved?
>
>> In any case, table markers are a much needed feature that makes it
>> possible to generate a wider range of statement type documents.
>
>
> Do you want to use a formatter with uncontrolled computational
> complexity in border cases? So that your rendering workflow gets stuck
> on a seemingly innocent document?
No, but I would like to generate a statement with sub totals carried
across pages. I'm sure there is a solution to this problem. Perhaps it
doesn't fit well into traditional layout algorithms, so it is a
opportunity to develop a new one ;)
Chris
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
Received on Mon Nov 7 03:22:18 2005
This archive was generated by hypermail 2.1.8 : Mon Nov 07 2005 - 03:22:19 PST