Another page-related question: page-position="last"

[Andreas L Delmelle <a_...@pandora.be>]

Hi,

(Apologies for the many posts... I'm definitely on a roll :-))

Now that it has been made clear to me that the layout-engine first 
calculates *all* break-possibilities, IMO this also seems to make 
implementing page-position="last" much, much easier.

Assuming that no areas are generated until the full element list is 
known, I'm thinking once you have created the Knuth-element list, 
instead of starting at element index zero to generate the areas, it 
would also be possible to have the algorithm start at the last element 
in the list until we reach the first break-possibility that would make 
the content exceed the height page-master whose page-position is 
"last", no?
At the very least, it would enable us to mark the break-possibility at 
which the algorithm should consider the last page-master... Obviously, 
we can't complete the full iteration in that direction, or we would run 
into problems determining the difference between odd and even, but it 
seems possible to iterate backwards once and assign a sort of 
'favorability degree' to each of break-possibilities --increase or 
decrease penalty values?--, taking into account that the last page 
*has* to start somewhere after the marked one --before is impossible, 
since it won't fit. The generated last page can be thrown away (or 
serialized to be re-used if the marked possibility just happens to 
coincide with the actual last page-break).

Am I getting this correctly?


Cheers,

Andreas

Re: Another page-related question: page-position="last"

[Andreas L Delmelle <a_...@pandora.be>]

On Sep 26, 2005, at 16:03, Jeremias Maerki wrote:

> It's an interesting idea. However, I suspect this will probably not be
> necessary. We should be able to make the breaker clever enough to 
> handle
> this particular case. ATM, I don't have free brain capacity to dive 
> into
> this (even though this is an important and long-awaited feature) but it
> may make sense to gather ideas and notes from the mailing list archives
> and put these on a Wiki page. I remember that several approaches have
> been discussed in the past even though they haven't had anything to do
> with our current breaking approach.

OK, I was just probing... Since that 'spark' --referring to your recent 
response to my completely misguided idea on tables ;-)-- lit my fire, 
I'm beginning to see all sorts of possibilities. Some things are 
falling into place now --been re-reading the Wiki docs, and browsing 
through the Knuth-related code, and this all makes very much more sense 
now.
(Haven't read Knuth's book/paper myself yet, so that was still a bit of 
a mystery to me)

When I find some time, I'll see what ideas I can dig up from the 
archives, and how they may possibly relate (or be translated) to our 
current layout code.


Cheers,

Andreas

Re: Another page-related question: page-position="last"

[Jeremias Maerki <de...@jeremias-maerki.ch>]

It's an interesting idea. However, I suspect this will probably not be
necessary. We should be able to make the breaker clever enough to handle
this particular case. ATM, I don't have free brain capacity to dive into
this (even though this is an important and long-awaited feature) but it
may make sense to gather ideas and notes from the mailing list archives
and put these on a Wiki page. I remember that several approaches have
been discussed in the past even though they haven't had anything to do
with our current breaking approach.

On 23.09.2005 20:28:14 Andreas L Delmelle wrote:
> Hi,
> 
> (Apologies for the many posts... I'm definitely on a roll :-))
> 
> Now that it has been made clear to me that the layout-engine first 
> calculates *all* break-possibilities, IMO this also seems to make 
> implementing page-position="last" much, much easier.
> 
> Assuming that no areas are generated until the full element list is 
> known, I'm thinking once you have created the Knuth-element list, 
> instead of starting at element index zero to generate the areas, it 
> would also be possible to have the algorithm start at the last element 
> in the list until we reach the first break-possibility that would make 
> the content exceed the height page-master whose page-position is 
> "last", no?
> At the very least, it would enable us to mark the break-possibility at 
> which the algorithm should consider the last page-master... Obviously, 
> we can't complete the full iteration in that direction, or we would run 
> into problems determining the difference between odd and even, but it 
> seems possible to iterate backwards once and assign a sort of 
> 'favorability degree' to each of break-possibilities --increase or 
> decrease penalty values?--, taking into account that the last page 
> *has* to start somewhere after the marked one --before is impossible, 
> since it won't fit. The generated last page can be thrown away (or 
> serialized to be re-used if the marked possibility just happens to 
> coincide with the actual last page-break).
> 
> Am I getting this correctly?


Jeremias Maerki