Re: column balancing
On May 28, 2004, at 6:18 AM, Chris Bowditch wrote: A.M. wrote: Replying off-list: huh? Yeah... that threw me for a loop as well, especially since the reply came on list (as I think it should, being on-topic and all)... I'm not sure I really have a choice concerning the fop version. Considering I needed column balancing "yesterday", I'll take the route that gives me balanced columns ASAP. I haven't looked at the PDF rendering code yet, so (neglecting your desire for the dev version to move forward) would you argue that it would be easiest to add column balancing to the maintenance version or to the dev version? If I can add it quickly to the maintenance version, I would be happy to add the same functionality to the dev version later. Thanks. Thats understandable. Yes, it will be less hassle for you to add column balancing into the maintenance code. Just dont expect your changes to make it into the code base. If you are able to give us some help with the development version later that will be greatly appreciated. Chris Sounds good to me too. As far as PATCHing the maintenance code, I would still encourage any submitting PATCH made for the Maintenance branch. Developers can always look through bugzilla to see if there's something they want or need (like TIF output... or column balancing ;-)). As long as they have a good Subject/Title and Description... Web Maestro Clay
Re: column balancing
A.M. wrote: Replying off-list: huh? I'm not sure I really have a choice concerning the fop version. Considering I needed column balancing "yesterday", I'll take the route that gives me balanced columns ASAP. I haven't looked at the PDF rendering code yet, so (neglecting your desire for the dev version to move forward) would you argue that it would be easiest to add column balancing to the maintenance version or to the dev version? If I can add it quickly to the maintenance version, I would be happy to add the same functionality to the dev version later. Thanks. Thats understandable. Yes, it will be less hassle for you to add column balancing into the maintenance code. Just dont expect your changes to make it into the code base. If you are able to give us some help with the development version later that will be greatly appreciated. Chris
Re: column balancing
What Arnd says make sense. I would like to add that any development help you can give will be gratefully received. However, you need to be aware that the maintenance branch 0.20.5 has been frozen, so any patches you submit to 0.20.5 code are unlikely to make it into the code base. I'm not sure that multi column layouts work at all in the development version, but you are more than welcome to help. If you have any questions at all, please dont hesitate to ask. Chris Replying off-list: I'm not sure I really have a choice concerning the fop version. Considering I needed column balancing "yesterday", I'll take the route that gives me balanced columns ASAP. I haven't looked at the PDF rendering code yet, so (neglecting your desire for the dev version to move forward) would you argue that it would be easiest to add column balancing to the maintenance version or to the dev version? If I can add it quickly to the maintenance version, I would be happy to add the same functionality to the dev version later. Thanks. ¬¬¬ AgentM [EMAIL PROTECTED] ¬¬¬
Re: column balancing
[EMAIL PROTECTED] wrote: "A.M." <[EMAIL PROTECTED]> wrote 27.05.2004 16:27:29: Excuse me for being annoying with the column balancing issue (from fop-user), but it's something that we crucially need. I would like to offer my time to implement this- however it's not clear to me which block attributes are relevant to this. Could someone point me to the page of the spec covering this? (Column balancing is unfortunately the only thing keeping us from FOP.) Thanks. As far as I can see, column balancing is not really defined as a mechanism in the XSL recommendation. My interpretation so far is that to do column balancing if a spanned block follows on the same page and not to do it if no spanned blocks follows, is one of several allowed user agent behaviours - and the one that makes the most sense as a default. If your or someone else finds something in the XSL recommendation that more precisely defines what should happen, I would be grateful for a pointer as well. What Arnd says make sense. I would like to add that any development help you can give will be gratefully received. However, you need to be aware that the maintenance branch 0.20.5 has been frozen, so any patches you submit to 0.20.5 code are unlikely to make it into the code base. I'm not sure that multi column layouts work at all in the development version, but you are more than welcome to help. If you have any questions at all, please dont hesitate to ask. Chris
Re: column balancing
"A.M." <[EMAIL PROTECTED]> wrote 27.05.2004 16:27:29: > Excuse me for being annoying with the column balancing issue (from > fop-user), but it's something that we crucially need. I would like to > offer my time to implement this- however it's not clear to me which > block attributes are relevant to this. Could someone point me to the > page of the spec covering this? (Column balancing is unfortunately the > only thing keeping us from FOP.) Thanks. As far as I can see, column balancing is not really defined as a mechanism in the XSL recommendation. My interpretation so far is that to do column balancing if a spanned block follows on the same page and not to do it if no spanned blocks follows, is one of several allowed user agent behaviours - and the one that makes the most sense as a default. If your or someone else finds something in the XSL recommendation that more precisely defines what should happen, I would be grateful for a pointer as well. My 2 cents, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
column balancing
Excuse me for being annoying with the column balancing issue (from fop-user), but it's something that we crucially need. I would like to offer my time to implement this- however it's not clear to me which block attributes are relevant to this. Could someone point me to the page of the spec covering this? (Column balancing is unfortunately the only thing keeping us from FOP.) Thanks. ¬¬¬ AgentM [EMAIL PROTECTED] ¬¬¬
RE: Column Balancing
Hi,
In case anyone else has a similar problem there is a simple (and very
obvious) fix:
In: BodyAreaContainer.resetSpanArea(), After line:
newHeight += 2 * 15600;
Add:
if(newHeight>getRemainingHeight()) {
newHeight = getRemainingHeight();
}
You can then tweak the newHeight safety margin till it works with your
content, without the columns overlapping the footer.
Yes, I don't know why it took me so long to see this ether.
Barnaby
>> My material contains a lot of tables with keep-together's and
external graphics. The image/table which are just too big to fit in the
estimated height of the first column are correctly move into the second
column, but this causes the second column to become longer then the
estimated maximum span height, this in turn causes fop to insert a page
break and move the end of the second column to the next page. However
this looks very odd as often 80% of the original page is still blank.
Fop already has a safety margin built into
BodyAreaContainer.resetSpanArea() to address this problem, however it is
set to small for my content.
>> You can easily overcome this problem by increasing the safety margin
which is added to maxHeigh in resetSpanArea() (from 2 * 15600, to 2 *
45600 in my case). This has the added benefit that it causes the first
column be about 4cm longer then the second before each span, which adds
some much needed white space to my layout.
>> However this introduces a new problem (which must be present to a
lesser degree anyway), the safety margin added in resetSpanArea() is
added after the check to see if the span's content fits on the page,
this means that if the content already filled the page, the span's new
height is increased by the safety margin and overlaps with the footer.
>> As far as I can see there are two ways to work around this:
>> Disable the column balancing when the contence of a span overflows
the page - simple set the column heights to the avaible size and then
fit as much content into column one followed by column two. (This must
be what happens on the last page of a flow).
(In fact the solution is even easier, simply don't let the column height
grow bigger then the page. The code already handles moving anything that
doesn't fit onto the next page.)
>> Change where the safety margin is added so that it is taken into
account when checking if the content fits on the page. This would cause
some unforinate white space at the bottom right of every page but I
could live with this.
>> Whilst these sound fairly simple, my Java experience is limited and I
have not been able to follow though the fop structure to workout where
to implement these changes - could anyone give my any guidance on where
to start and/or which of the approaches might be easer to implement
given the way fop works.
Re: Column Balancing
Barnaby Shearer wrote: (I am using FOP 0.20.5 on the Sun JDK 1.4 under windows XP) Thanks for the analysis but FOP 0.20.5 is frozen code I'm afraid. FOP has been redesigned to support keeps (on all FOs) and development is focused on the redesigned branch in CVS Head. Column balancing will be addressed in the new code. Thanks, Chris
Column Balancing
Hi, I am using fop with a two column layout and am having some problems with the column balancing when there is a spanned block midway though a page. My material contains a lot of tables with keep-together's and external graphics. The image/table which are just too big to fit in the estimated height of the first column are correctly move into the second column, but this causes the second column to become longer then the estimated maximum span height, this in turn causes fop to insert a page break and move the end of the second column to the next page. However this looks very odd as often 80% of the original page is still blank. Fop already has a safety margin built into BodyAreaContainer.resetSpanArea() to address this problem, however it is set to small for my content. You can easily overcome this problem by increasing the safety margin which is added to maxHeigh in resetSpanArea() (from 2 * 15600, to 2 * 45600 in my case). This has the added benefit that it causes the first column be about 4cm longer then the second before each span, which adds some much needed white space to my layout. However this introduces a new problem (which must be present to a lesser degree anyway), the safety margin added in resetSpanArea() is added after the check to see if the span's content fits on the page, this means that if the content already filled the page, the span's new height is increased by the safety margin and overlaps with the footer. As far as I can see there are two ways to work around this: Disable the column balancing when the contence of a span overflows the page - simple set the column heights to the avaible size and then fit as much content into column one followed by column two. (This must be what happens on the last page of a flow). Change where the safety margin is added so that it is taken into account when checking if the content fits on the page. This would cause some unforinate white space at the bottom right of every page but I could live with this. Whilst these sound fairly simple, my Java experience is limited and I have not been able to follow though the fop structure to workout where to implement these changes - could anyone give my any guidance on where to start and/or which of the approaches might be easer to implement given the way fop works. (I am using FOP 0.20.5 on the Sun JDK 1.4 under windows XP) Thank you, Barnaby
