Hi Vincent (and others, if somebody wants to join, it's not a private conversation),
> > 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"> That's possible. I could, by default, translate a given space-before of x into a space-before.minimum=".9*x" space-before.optimum="x" space-before.maximum="1.1*x" > 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. Actually, the inheritance is working fine. I have a tree structure with flow and blocks and foxNeedsBalancing is set correctly. But PageBreaker calls LayoutContext.getFoxNeedsBalancing(), so somewhere I have to call LayoutContext.setFoxNeedsBalancing(Block.getFoxNeedsBalancing()). I'm just not yet sure, where. >> 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. Well, I need the orphan-widow function too. So it's an issue anyway. But one for next week. > 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). Which, of course, is not the case. Tables, images, headlines, ... > > 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. Well, a bridge to cross when I reach it. Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de
