Re: Another page-related question: page-position=last
Ah, so we need to define first, what we really want to expect. :-) Does the spec say anything about the expected behaviour? On 02.10.2005 00:57:07 J.Pietschmann wrote: Jeremias Maerki wrote: On 27.09.2005 16:38:23 Luca Furini wrote: [the usual layout oscillation/convergence problem] What is the expected output? In this case it has to generate a blank page IMO. The expected output is that there is some content (area with bpd0) on the last page, even if this sounds suboptimal. J.Pietschmann Jeremias Maerki
Re: Another page-related question: page-position=last
On Oct 3, 2005, at 16:11, Jeremias Maerki wrote: On 02.10.2005 00:57:07 J.Pietschmann wrote: Jeremias Maerki wrote: On 27.09.2005 16:38:23 Luca Furini wrote: [the usual layout oscillation/convergence problem] What is the expected output? In this case it has to generate a blank page IMO. The expected output is that there is some content (area with bpd0) on the last page, even if this sounds suboptimal. Ah, so we need to define first, what we really want to expect. :-) Does the spec say anything about the expected behaviour? I believe this can be (more or less) inferred from the fact that there are actually three sub-conditions, namely: page-position, odd-or-even and blank-or-not-blank. Given that: a) all three sub-conditions have to be true for the condition on the fo:conditional-page-master to be true (= to make it eligible for selection) b) the initial value for 'blank-or-not-blank' is 'any' Then I'd conclude that both the described expected outputs --blank page or one filled with some content-- are allowed in case there is no explicit blank-or-not-blank sub-condition specified on the fo:c-p-m in question (or an explicit any, which comes down to the same thing). If and only if you have a fo:c-p-m with both page-position=last and blank-or-not-blank=blank, the output of one blank last page is the only correct output. Same thing for Joerg's expectation, which is the only correct output in case you have page-position=last and blank-or-not-blank=not-blank. Note: in both cases I'm assuming this to be the only fo:c-p-m with a condition page-position=last. I'm not absolutely sure, so correct me if I'm wrong... For instance: I'm wondering whether the conditions *have* to be met, so that the layout-engine would, if necessary, have to perform all sorts of magic tricks to force the content to meet the criteria, or whether OTOH, the layout-engine only *has* to choose a particular fo:c-p-m if the criteria actually are met (?) Anyone? Cheers, Andreas
Re: Another page-related question: page-position=last
On Oct 3, 2005, at 21:22, J.Pietschmann wrote: Umm, emm, blank means no area at all on the page body, not even one with bpd=0. E.g. fo:flow ... fo:block/ fo:block break-before=page/ /fo:flow would create two non-blank pages. Or so I think. I see and fully agree, but IIRC, one of the ideas was to create a sort of dummy-area (internally, not corresponding to a FO in the document), so that the last page-master would always be used, even if the next-to-last page can hold all of the remaining content at a given point. AFAICT, this would *only* be acceptable if the page-master in question doesn't have an explicit non-blank constraint. In any case, you're right about the above example generating two non-blank (yet empty) pages. So, a page-master with explicit blank constraint can never be used for either of them. But now, I'm still wondering about the last question in my earlier post... :-/ If we have: fo:conditional-page-master page-position=last blank-or-not-blank=not-blank a) Does this page-master have to be used, period? (= If there are no areas left to fill up the last page, layout needs to backtrack in order to satisfy both conditions.) b) Does it have to be used only in case both criteria are met at the same time? (= If there are no areas left to fill up an eventual last page, then this page-master is simply never eligible for selection.) I'm inclined to believe b), but again, not absolutely --or: absolutely not-- certain about this... Make it page-position=last and odd-or-even=odd: does that mean that we have to make sure that the page-sequence always contains an odd number of pages, or that that page-master is eligible for selection only if the last page turns out to have an odd number? Cheers, Andreas
Re: Another page-related question: page-position=last
Jeremias Maerki wrote: On 27.09.2005 16:38:23 Luca Furini wrote: [the usual layout oscillation/convergence problem] What is the expected output? In this case it has to generate a blank page IMO. The expected output is that there is some content (area with bpd0) on the last page, even if this sounds suboptimal. J.Pietschmann
Re: Another page-related question: page-position=last
Jeremias Maerki wrote: What is the expected output? In this case it has to generate a blank page IMO. Oh, right, I did not think of an empty page! :-) The problem is with the page x of y hack that won't work like this if the last empty block ends up on the second-to-last page. [...] What about the following approach? Run the breaker without special last-page handling, then inspect the allocated BPD for the last part. If it fits into the last page, just exchange the page-master (*) and paint it there. If it doesn't fit, paint it using the non-last page-master and add a blank page with the last page-master. If there's a box w=0 at the end of the element list, force a new part and paint that on the last page to handle the page x of y case. I think this would work with my idea too: in this case, if the last empty block and the difference in page bpd (that cannot be parted) do not fit in the non-last page under construction, they would be placed in a new page; so, a page-number-citation pointing to the empty block would return the last page-number. This would avoid the need to exchange page-masters, and to have a special handling for zero-width box at the end of the sequence. Regards Luca
Re: Another page-related question: page-position=last
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. When the page bpd depends on the page-masters, things becomes very strange. Not only it's difficult to implement the page-master choice, but even to understand what should be the expected result! :-) For example: let's suppose the breaker is working, and it has to place the last 25 lines of a page-sequence. The page-master for the last page has a bpd allowing no more than 20 lines, while the other page-masters can contain up to 30 lines. What happens? If the breaker starts building a last page it soon realizes that it would not contain all the remaining content, so it would be no more a last page. But if it starts building a non-last page, it reaches the end of the content, and has to turn it into a last page, which is impossible. What is the expected output? The only way I see to satisfy the property is to create two more pages: one non-last page, partially empty, with less than 25 lines (24 or fewer, if there are keeps, widows or orphans) and a last page with the remaining lines. This sort of problems happens only if the last page is smaller than the previous ones: otherwise, the breaker can always try to build a non-last page, eventually moving all its content into a last page. Now I think of this ... an idea, that could work at least when the non-last pages have the same bpd and the last page a smaller one, could be to modify a little the elements appended at the end of the sequence, so that they have a width equal to the difference (nonLastBPD - lastBPD). This way, the last page created by the breaker will have an apparent width of nonLastBPD, but the content placed inside it will have an overall bpd equal to nonLastBPD - (nonLastBPD - lastBPD) = lastBPD What do you think? Regards Luca
Re: Another page-related question: page-position=last
On 27.09.2005 16:38:23 Luca Furini wrote: 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. When the page bpd depends on the page-masters, things becomes very strange. Not only it's difficult to implement the page-master choice, but even to understand what should be the expected result! :-) For example: let's suppose the breaker is working, and it has to place the last 25 lines of a page-sequence. The page-master for the last page has a bpd allowing no more than 20 lines, while the other page-masters can contain up to 30 lines. What happens? If the breaker starts building a last page it soon realizes that it would not contain all the remaining content, so it would be no more a last page. But if it starts building a non-last page, it reaches the end of the content, and has to turn it into a last page, which is impossible. What is the expected output? In this case it has to generate a blank page IMO. Note that this is a scenario that is important for Switzerland where we have Einzahlungsscheine (a preprinted form used for payments). These are often expected to be on the last page of the document. So far I always had to persuade my clients that putting the Einzahlungsschein on the first page is not so bad. :-) The problem is with the page x of y hack that won't work like this if the last empty block ends up on the second-to-last page. The only way I see to satisfy the property is to create two more pages: one non-last page, partially empty, with less than 25 lines (24 or fewer, if there are keeps, widows or orphans) and a last page with the remaining lines. That sounds suboptimal. The less breaks, the better. Better have a blank page. This sort of problems happens only if the last page is smaller than the previous ones: otherwise, the breaker can always try to build a non-last page, eventually moving all its content into a last page. Now I think of this ... an idea, that could work at least when the non-last pages have the same bpd and the last page a smaller one, could be to modify a little the elements appended at the end of the sequence, so that they have a width equal to the difference (nonLastBPD - lastBPD). This way, the last page created by the breaker will have an apparent width of nonLastBPD, but the content placed inside it will have an overall bpd equal to nonLastBPD - (nonLastBPD - lastBPD) = lastBPD What do you think? I don't get it, yet. What about the following approach? Run the breaker without special last-page handling, then inspect the allocated BPD for the last part. If it fits into the last page, just exchange the page-master (*) and paint it there. If it doesn't fit, paint it using the non-last page-master and add a blank page with the last page-master. If there's a box w=0 at the end of the element list, force a new part and paint that on the last page to handle the page x of y case. (*) Doesn't work if the available IPD is different. A restart will be necessary in this case which could result in an overflow of the last page which means that the content can still be reset to the old page-master and a blank last page has to be generated. Jeremias Maerki
Re: Another page-related question: page-position=last
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
Re: Another page-related question: page-position=last
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
Another page-related question: page-position=last
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
