You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/03/27 12:48:52 UTC
Suggest FOP-0.18.1 for the 30th
Hi, all
Apart from the resources/ thing concerning AWT viewer (you don't see the
images), and another bug pointed out by Daniel Bradby which involves
printing (for which he has a patch), there is at least one other defect
submitted by Petr Andrs which sounds non-trivial.
I suggest that we fix or try to fix all of the above (I'll hack away if
nobody else has time) before end of week. I also suggest that we shoot for a
FOP-0.18.1 release as of Friday the 30th. I respectfully request that nobody
do any CVS commits that are enhancements or new code for the next 3 or 4
days, so that CVS that reflects bug fixes don't get snarled up in potential
problems.
Thoughts? Opinions? Comments? I'll say one thing straight off, this last
release (FOP 0.18.0) reflects a lack of discipline on my part - I've had
lots to do but that's no excuse for not checking Bugzilla a bit better and
doing something positive about submitted defects. People are going to stop
reporting bugs if they see or believe that Bugzilla is not being monitored.
Speaking for myself only - no aspersions being cast on anyone else.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Table breaking bug (was Re: Suggest FOP-0.18.1 for the 30th)
Posted by Karen Lease <kl...@club-internet.fr>.
Guillaume, thanks for your feedback and examples.
I haven't had time to check your examples yet, but I have found one
unintended side effect of my change: table cell heights are now bigger
than they should be. I am working on fixing that (hopefully without
breaking anything else) and I will look at your tests. Unfortunately, I
fear this will not make it into 0.18.1.
Salut,
Karen
Guillaume Laurès wrote:
>
> Martin Roob a écrit :
>
> > Hello Karen,
> > for me your fix works exactly how it should.
> > My table now are broken where i exspect them to be.
> > I don' see any bad side effects in the moment.
> > Thanks
> > Martin
>
> I really can't tell the same, unfortunately.
>
> This patch indeed solved the problem for the http://www.lra.fr/fo-tests/om23.fo document:
> http://www.lra.fr/fo-tests/om23-cvs.pdf
> But it's a cut down version of our generated fo documents (to make it clearer, I removed by hand all the elements
> other than the table).
>
> Here is a sample of a complete fo file we deal with, based on the same xml doc as the cut down one:
> http://www.lra.fr/fo-tests/om23-bad-complete.fo
> the resulting pdf with 0.17.0:
> http://www.lra.fr/fo-tests/om23-bad-complete.pdf
> and the resulting pdf with cvs patched (the one that cleanly solved the issue in fo-tests/om23.fo):
> http://www.lra.fr/fo-tests/om23-bad-complete-cvs.pdf
>
> Here is the same document, with just one line (Préparer la prise de décision en groupe : poser le problème,
> questionner, rechercher les informations) cut in the right column, it displays fine, but the is unused space at
> the bottom:
> http://www.lra.fr/fo-tests/om23-good-complete.fo
> the resulting pdf with 0.17.0:
> http://www.lra.fr/fo-tests/om23-good-complete.pdf
> and as you can see, the cvs version introduces some significant differences in the layout, but that may be
> related to the generated fo code not being clean itself. Besides, it doesn't fit anymore on a single page,
> whereas it does with 0.17.0... (om23-good-complete.pdf)
>
> http://www.lra.fr/fo-tests/om23-good-complete-cvs.pdf
>
> I hope this will help resolving the issue, if you need some more tests just ask, I'd be happy to make them if it
> can help resolving the issue.
>
> If the probelm persist because I'm using the fo language out of its range, tell me too... but I don't think so
> since the evaluation version of xep did render the table correctly in all the cases (though other parts of the
> rendering turned out to be really strange).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Suggest FOP-0.18.1 for the 30th
Posted by Guillaume Laurès <la...@lra.fr>.
Martin Roob a écrit :
> Hello Karen,
> for me your fix works exactly how it should.
> My table now are broken where i exspect them to be.
> I don' see any bad side effects in the moment.
> Thanks
> Martin
I really can't tell the same, unfortunately.
This patch indeed solved the problem for the http://www.lra.fr/fo-tests/om23.fo document:
http://www.lra.fr/fo-tests/om23-cvs.pdf
But it's a cut down version of our generated fo documents (to make it clearer, I removed by hand all the elements
other than the table).
Here is a sample of a complete fo file we deal with, based on the same xml doc as the cut down one:
http://www.lra.fr/fo-tests/om23-bad-complete.fo
the resulting pdf with 0.17.0:
http://www.lra.fr/fo-tests/om23-bad-complete.pdf
and the resulting pdf with cvs patched (the one that cleanly solved the issue in fo-tests/om23.fo):
http://www.lra.fr/fo-tests/om23-bad-complete-cvs.pdf
Here is the same document, with just one line (Préparer la prise de décision en groupe : poser le problème,
questionner, rechercher les informations) cut in the right column, it displays fine, but the is unused space at
the bottom:
http://www.lra.fr/fo-tests/om23-good-complete.fo
the resulting pdf with 0.17.0:
http://www.lra.fr/fo-tests/om23-good-complete.pdf
and as you can see, the cvs version introduces some significant differences in the layout, but that may be
related to the generated fo code not being clean itself. Besides, it doesn't fit anymore on a single page,
whereas it does with 0.17.0... (om23-good-complete.pdf)
http://www.lra.fr/fo-tests/om23-good-complete-cvs.pdf
I hope this will help resolving the issue, if you need some more tests just ask, I'd be happy to make them if it
can help resolving the issue.
If the probelm persist because I'm using the fo language out of its range, tell me too... but I don't think so
since the evaluation version of xep did render the table correctly in all the cases (though other parts of the
rendering turned out to be really strange).
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Suggest FOP-0.18.1 for the 30th
Posted by Martin Roob <Ma...@objekt-management.de>.
Hello Karen,
for me your fix works exactly how it should.
My table now are broken where i exspect them to be.
I don' see any bad side effects in the moment.
Thanks
Martin
Karen Lease schrieb:
>
> Bonjour Guillaume,
>
> Attached is a diff against 1.17 which is the latest CVS of Area.java. I
> tried diffing against the version in the 0.17 jar, but there are too
> many differences, because since then I made a lot of changes in the
> Border/Padding handling.
> Most of the differences you see are just javadoc comments. The important
> one is in the method getMaxHeight. I think the change in setHeight is
> probably a good idea too. Let me know how it works.
>
> Salut,
> Karen Lease
>
> > Guillaume Laurès wrote:
> >
> > Le 28 Mar 2001 00:37:05 +0200, Karen Lease a écrit :
> >
> > > There were a couple of reports of strange page breaking behavior on the
> >
> > > list a week ago. I have a change which fixes this, but I need to make
> >
> > > sure it won't break something else! The change itself is very minor, but
> >
> > > since it's in Area, it could have some wider effects. I'll try to get it
> >
> > > in before Friday.
> >
> > Could youi provide the diff (against 0.17 sources) for example ?
> > I could tell you if it fix the thing and if for us nothing else is
> > broken then...
> >
> > Thanks
> > Guillaume Laurès
> > Responsable systemes et Techniques - EBI
> > Tél: [33] (0)1 46 29 68 24
>
> ------------------------------------------------------------------------
> Index: src/org/apache/fop/layout/Area.java
> ===================================================================
> RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/Area.java,v
> retrieving revision 1.17
> diff -c -r1.17 Area.java
> *** src/org/apache/fop/layout/Area.java 2001/03/04 21:38:41 1.17
> --- src/org/apache/fop/layout/Area.java 2001/03/28 20:28:36
> ***************
> *** 69,74 ****
> --- 69,77 ----
> /* max size in line-progression-direction */
> protected int maxHeight;
>
> + /**
> + * Total height of content of this area.
> + */
> protected int currentHeight = 0;
>
> // used to keep track of the current x position within a table. Required for drawing rectangle links.
> ***************
> *** 96,101 ****
> --- 99,112 ----
> setFontState(fontState);
> }
>
> + /**
> + * Creates a new <code>Area</code> instance.
> + *
> + * @param fontState a <code>FontState</code> value
> + * @param allocationWidth the inline-progression dimension of the content
> + * rectangle of the Area
> + * @param maxHeight the maximum block-progression dimension
> + */
> public Area (FontState fontState, int allocationWidth, int maxHeight) {
> setFontState(fontState);
> this.allocationWidth = allocationWidth;
> ***************
> *** 138,143 ****
> --- 149,162 ----
> return this.allocationWidth ;
> }
>
> + /**
> + * Set the allocation width.
> + * @param w The new allocation width.
> + * This sets content width to the same value.
> + * Currently only called during layout of Table to set the width
> + * to the total width of all the columns. Note that this assumes the
> + * column widths are explicitly specified.
> + */
> public void setAllocationWidth(int w) {
> this.allocationWidth = w;
> this.contentRectangleWidth = this.allocationWidth;
> ***************
> *** 159,176 ****
> --- 178,211 ----
> return this.fontState;
> }
>
> + /**
> + * Returns content height of the area.
> + *
> + * @return Content height in millipoints
> + */
> public int getContentHeight() {
> return this.currentHeight;
> }
>
> + /**
> + * Returns allocation height of this area.
> + * The allocation height is the sum of the content height plus border
> + * and padding in the vertical direction.
> + *
> + * @return allocation height in millipoints
> + */
> public int getHeight() {
> return this.currentHeight + getPaddingTop() + getPaddingBottom() +
> getBorderTopWidth() + getBorderBottomWidth();
> }
>
> public int getMaxHeight() {
> + // Change KDL: return max height of content rectangle
> + return this.maxHeight;
> + /*
> return this.maxHeight - getPaddingTop() - getPaddingBottom() -
> getBorderTopWidth() - getBorderBottomWidth();
> + */
> }
>
> public Page getPage() {
> ***************
> *** 241,246 ****
> --- 276,282 ----
> this.absoluteHeight += amount;
> }
>
> + // Remove allocation height of child
> public void removeChild(Area area) {
> this.currentHeight -= area.getHeight();
> this.absoluteHeight -= area.getHeight();
> ***************
> *** 269,274 ****
> --- 305,316 ----
> this.bp = bp;
> }
>
> + /**
> + * Return space remaining in the vertical direction (height).
> + * This returns maximum available space - current content height
> + * Note: content height should be based on allocation height of content!
> + * @return space remaining in base units (millipoints)
> + */
> public int spaceLeft() {
> return maxHeight - currentHeight;
> }
> ***************
> *** 276,290 ****
> public void start() {
> }
>
> public void setHeight(int height) {
> ! if (height > currentHeight)
> currentHeight = height;
> ! absoluteHeight = height;
>
> ! if (currentHeight > getMaxHeight())
> currentHeight = getMaxHeight();
> ! absoluteHeight = getMaxHeight();
> !
> }
>
> public void setMaxHeight(int height) {
> --- 318,342 ----
> public void start() {
> }
>
> +
> + /**
> + * Set the content height to the passed value if that value is
> + * larger than current content height. If the new content height
> + * is greater than the maximum available height, set the content height
> + * to the max. available (!!!)
> + *
> + * @param height allocation height of content in millipoints
> + */
> public void setHeight(int height) {
> ! if (height > currentHeight) {
> currentHeight = height;
> ! absoluteHeight = height; // Looks like this should be in a block!
> ! }
>
> ! if (currentHeight > getMaxHeight()) {
> currentHeight = getMaxHeight();
> ! absoluteHeight = getMaxHeight();
> ! }
> }
>
> public void setMaxHeight(int height) {
> ***************
> *** 312,317 ****
> --- 364,371 ----
> return this.foCreator;
> }
>
> + // Function not currently used! (KLease, 16mar01)
> +
> public AreaContainer getNearestAncestorAreaContainer()
> {
> Area area = this.getParent();
> ***************
> *** 325,328 ****
> --- 379,383 ----
> public BorderAndPadding getBorderAndPadding() {
> return bp;
> }
> +
> }
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Suggest FOP-0.18.1 for the 30th
Posted by Karen Lease <kl...@club-internet.fr>.
Bonjour Guillaume,
Attached is a diff against 1.17 which is the latest CVS of Area.java. I
tried diffing against the version in the 0.17 jar, but there are too
many differences, because since then I made a lot of changes in the
Border/Padding handling.
Most of the differences you see are just javadoc comments. The important
one is in the method getMaxHeight. I think the change in setHeight is
probably a good idea too. Let me know how it works.
Salut,
Karen Lease
> Guillaume Laur�s wrote:
>
> Le 28 Mar 2001 00:37:05 +0200, Karen Lease a �crit :
>
> > There were a couple of reports of strange page breaking behavior on the
>
> > list a week ago. I have a change which fixes this, but I need to make
>
> > sure it won't break something else! The change itself is very minor, but
>
> > since it's in Area, it could have some wider effects. I'll try to get it
>
> > in before Friday.
>
> Could youi provide the diff (against 0.17 sources) for example ?
> I could tell you if it fix the thing and if for us nothing else is
> broken then...
>
> Thanks
> Guillaume Laur�s
> Responsable systemes et Techniques - EBI
> T�l: [33] (0)1 46 29 68 24
Re: Suggest FOP-0.18.1 for the 30th
Posted by Guillaume Laurès <la...@lra.fr>.
Le 28 Mar 2001 00:37:05 +0200, Karen Lease a �crit :
> There were a couple of reports of strange page breaking behavior on the
> list a week ago. I have a change which fixes this, but I need to make
> sure it won't break something else! The change itself is very minor, but
> since it's in Area, it could have some wider effects. I'll try to get it
> in before Friday.
Could youi provide the diff (against 0.17 sources) for example ?
I could tell you if it fix the thing and if for us nothing else is
broken then...
Thanks
Guillaume Laur�s
Responsable systemes et Techniques - EBI
T�l: [33] (0)1 46 29 68 24
Re: Suggest FOP-0.18.1 for the 30th
Posted by Karen Lease <kl...@club-internet.fr>.
There were a couple of reports of strange page breaking behavior on the
list a week ago. I have a change which fixes this, but I need to make
sure it won't break something else! The change itself is very minor, but
since it's in Area, it could have some wider effects. I'll try to get it
in before Friday.
-Karen
Arved Sandstrom wrote:
>
> Hi, all
>
> Apart from the resources/ thing concerning AWT viewer (you don't see the
> images), and another bug pointed out by Daniel Bradby which involves
> printing (for which he has a patch), there is at least one other defect
> submitted by Petr Andrs which sounds non-trivial.
>
> I suggest that we fix or try to fix all of the above (I'll hack away if
> nobody else has time) before end of week. I also suggest that we shoot for a
> FOP-0.18.1 release as of Friday the 30th. I respectfully request that nobody
> do any CVS commits that are enhancements or new code for the next 3 or 4
> days, so that CVS that reflects bug fixes don't get snarled up in potential
> problems.
>
> Thoughts? Opinions? Comments? I'll say one thing straight off, this last
> release (FOP 0.18.0) reflects a lack of discipline on my part - I've had
> lots to do but that's no excuse for not checking Bugzilla a bit better and
> doing something positive about submitted defects. People are going to stop
> reporting bugs if they see or believe that Bugzilla is not being monitored.
> Speaking for myself only - no aspersions being cast on anyone else.
>
> Regards,
> Arved Sandstrom
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org