Hi Georg,

Georg Datterl wrote:
 Hi Vincent,
<snip/>
Hmmm.
The diagnostic is quite easy: the first column doesn't contain any elastic space and doesn't exactly fill the page; so there's enough room for the spanning block to squeeze in one line of content, instead of being deferred to the next page. Set background-color="#F0F0F0" on the region-body to more easily see what's happening.


I have no idea, how elastic space is defined, but I guess, orphan-widow-control 
would then take care of that problem? I'll have to check but I think, there's 
no case, where a wide block in a two-column layout should break after one line.

Actually you would play with the space-before/after properties:
    <fo:block space-before.minimum="0.8em"
              space-before.optimum="1.0em"
              space-before.maximum="2.0em">

If the difference between minimum and maximum is big enough, that should
give FOP enough of flexibility to reach the bottom of the columns all
the time.
The widow and orphans properties might create trouble, although at their
default values of 2 that should be ok.


(As a side note, I saw you put the fox-needs-balancing property on the page-sequence element. I think you want to define it on the spanning block instead.)

Yes, error in the test file. I thought, I'd put fox-needs-balancing in fo:flow with default true and in fo:block with default inherit. So the spanning blocks ( which, I assume, are what I called wide blocks)

(Yes, sorry.)

don't necessarily have to know about the property in the fo-file but could as well overwrite the flow setting, if necessary. Which, by the way, works quite fine, now I just have to find, how the property is correctly transfered from Block of Flow to LayoutContainer.

Alright, it’s not an error then and is quite sensible actually. I’m
hoping that FO tree specialists will chime in to give you hints on that
regard. Hopefully there’s not much to do to get this inheritance
behaviour.


What eludes me in this particular case, though, is why the algorithm didn't put an additional line of Qs at the bottom of the first column since there is room for it.

Another think I just saw: On page two, the left column contains 41 lines, the right column one more and on page three, the first column has 43 lines.

This is normal and due to the ‘orphans’ and ‘widows’ properties...
Errr... no, this is not normal at all actually. There’s enough space to
put the last two lines of the ‘L’ paragraph on the first column.

And, speaking about that, the ‘orphans’ property on the ‘U’ paragraph is
at its default value of 2, so there shouldn’t be just one line of that
paragraph at the bottom of page 3.

It looks like on top of your need for an extension, bugs are appearing
just to make things even more complicated :-( However, the space
property like explained above should allow you to avoid most of those
issues, if you can use it.


Anyway, this suddenly makes the problem a lot more difficult, I'm afraid, 
because it becomes necessary to do something on the layout side.
I'm not too keen on it, I must say, since this whole area is likely to be 
revised when introducing the new approach to line- and page-breaking.
You can work around the problem by making sure that the columns will always exactly fill the pages, i.e. by adding elastic spaces between paragraphs. If your content is so made that at least one elastic space can be found on every column, then you should never encounter the issue.

Except if the column is filled by one single block?

Unfortunately yes... The work around is to define the height of the
region-body to be a multiple of the line-height. Provided, of course,
that all the lines will be of the same height (16pt * 1.2 in your sample
file).


Or it will occur rarely enough that you will be happy to manually fix it when it does.

No, manual fixing is bad, since I expect pdfs with up to 1000 pages.
Then it's still worth implementing the solution I proposed, but it will have to be demoted from the status of official FOP extension to the less glossy one of cheap unofficial hack. At any rate, I think it's your only hope to have something working by the 5th of December... Then it's always possible to discuss about a more definitive solution.

You know how it works. If I have a working hack by next Friday, I'll never find 
the time to make it a clean, official extension. :-(

I know... but if the hack is there then there’s a small chance that when
this area of the code is revised it will be remembered and a clean
solution will come naturally.


HTH,
Vincent

Reply via email to