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 Art Welch <ar...@EASTPOINT.COM> on 2000/12/21 02:00:01 UTC
Compare.class
I mentioned this before (months ago), but apparently it was missed (or
ignored).
I noticed that the Compare.class in lib does not seem to have been
recompiled. I noticed this because it fails when I attempt to run
runtests.sh because of a Vector.add() call that has been long since removed
from Compare.java. Compiling a new Compare.class from Compare.java (no
changes to the source) fixes the problem.
This is just a minor annoyance, but it would be nice if it were fixed. I
also wonder if perhaps the other classes in lib could also be having this
problem. Is there something that can be done to keep these up to date?
Thank You,
Art
Re: Compare.class
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 12:11 PM 12/27/00 +0100, Fotis Jannidis wrote:
>Art,
>
>thanks for pointing out the problem. Actually we treated the files in
>/lib as ready built libraries which don't need any updating, at least
>not from our side, but situation has changed when we began putting
>our own ant tasks there.
>The only way to handle this is imho to have a separate build file for
>these files. We can't use a target in build.xml because all ant tasks
>have to be available at startup time of ant and some of the tasks rely
>on an existing fop.jar. So the one who builds the release has to
>rebuild also the task files for the release. I have changed build.bat
>and written an anttask.xml. Kelly is putting in any necessary
>changes for the xalan 2 support and he will afaik also change
>build.sh.
Hi, Fotis
Duly noted. Kelly may not get around to doing any of this before the next
release (only a few days away), since he is still on that hedonistic ski
trip, so I'll modify build.sh. I don't plan to make any mods for TRAX; I
haven't been following that closely enough.
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
Re: AWTRenderer complex body regions
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Daniel
Point taken. I put in the empty methods just so AWTRenderer would compile, a
couple of days ago, and I really should have followed up by now with pretty
much what you have.
Unless Someone Beats Me To It (should be a FOP acronym...USBMTI), I'll
review your patches and get stuff up into CVS within 24 hours.
Thank you.
Arved
P.S. No faux-pas at all. You or anyone, you see something that can be done
better, hit us with the suggestions and patches, and piss us off a bit with
repeated posts until we pay attention. We committers don't own the project
or the code, we just guide it.
At 01:44 PM 12/21/00 +1100, Daniel Bradby wrote:
>
>I've been using the AWTRenderer quite happily in 0.15 until I got a cvs
>update and it stopped working all together. Is there any other way to
>embed FOP into my app so I can print the rendered result?
>
>It looks like some empty methods were created to suppot complex body
>areas. So taking straight from the PDFRenderer is the additional methods
>in a patch (this is my first commit to this sort of project so pls
>forgive any faux-pas). I ran some of the samples over it and it seemed
>to work ok.
>
>I haven't looked in detail at the architecture but this sort of code
>copy doesn't feel very clean.
>
>btw I'm very happy now table-header is working :)
>
>---
>Daniel Bradby
>daniel@bjs.com.auIndex: AWTRenderer.java
>===================================================================
>RCS file:
/home/cvspublic/xml-fop/src/org/apache/fop/render/awt/AWTRenderer.java,v
>retrieving revision 1.16
>diff -u -r1.16 AWTRenderer.java
>--- AWTRenderer.java 2000/12/18 04:56:15 1.16
>+++ AWTRenderer.java 2000/12/21 02:19:01
>@@ -357,11 +357,27 @@
> }
> }
>
>- // empty for now
>- public void renderBodyAreaContainer(BodyAreaContainer area) {}
>+ public void renderBodyAreaContainer(BodyAreaContainer area) {
>+ renderAreaContainer(area.getBeforeFloatReferenceArea());
>+ renderAreaContainer(area.getFootnoteReferenceArea());
>
>- // empty for now
>- public void renderSpanArea(SpanArea area) {}
>+ // main reference area
>+ Enumeration e = area.getMainReferenceArea().getChildren().elements();
>+ while (e.hasMoreElements()) {
>+ org.apache.fop.layout.Box b =
>+ (org.apache.fop.layout.Box) e.nextElement();
>+ b.render(this); // span areas
>+ }
>+ }
>+
>+ public void renderSpanArea(SpanArea area) {
>+ Enumeration e = area.getChildren().elements();
>+ while (e.hasMoreElements()) {
>+ org.apache.fop.layout.Box b =
>+ (org.apache.fop.layout.Box) e.nextElement();
>+ b.render(this); // column areas
>+ }
>+ }
>
> private void doFrame(org.apache.fop.layout.Area area) {
> int w, h;
>
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
AWTRenderer complex body regions
Posted by Daniel Bradby <da...@bjs.com.au>.
I've been using the AWTRenderer quite happily in 0.15 until I got a cvs
update and it stopped working all together. Is there any other way to
embed FOP into my app so I can print the rendered result?
It looks like some empty methods were created to suppot complex body
areas. So taking straight from the PDFRenderer is the additional methods
in a patch (this is my first commit to this sort of project so pls
forgive any faux-pas). I ran some of the samples over it and it seemed
to work ok.
I haven't looked in detail at the architecture but this sort of code
copy doesn't feel very clean.
btw I'm very happy now table-header is working :)
---
Daniel Bradby
daniel@bjs.com.au
Re: Compare.class
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
From: Art Welch <ar...@EASTPOINT.COM>
> I mentioned this before (months ago), but apparently it was missed (or
> ignored).
Missed, sorry.
> I noticed that the Compare.class in lib does not seem to have been
> recompiled. I noticed this because it fails when I attempt to run
> runtests.sh because of a Vector.add() call that has been long since removed
> from Compare.java. Compiling a new Compare.class from Compare.java (no
> changes to the source) fixes the problem.
The classes in /lib haven't been included into the build process; they
should be. I 'll look into this, if Kelly hasn't done it already.
Fotis