Re: FOP Style Guide (update)
Jeremias Maerki wrote: if (isEnabled()) return true; Surely: return isEnabled(); is far, far better - it more clearly expresses your intent. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Style Guide (update)
Michael Gratton wrote:
Surely:
return isEnabled();
is far, far better - it more clearly expresses your intent.
Err, unless you don't want to return if isEnabled() returns false.. I
think I might go get that coffee now..
:(
Anyway, I don't think
if (isEnabled()) {
return true;
}
is too onerous. Sun's code conventions reccomend it.
/mike
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: avalon-framework lib in distribution
Jens Khnberger wrote: thanks a lot, it worked. If u want to put the avalon-framework.jar I generated into the distribution, I can send it to you. Well, I'm not a committer, so we'll see if any of those who are want it.. :) When I create a pdf document I get output into my (log4j-)logfile, but I also get the following warning on the console: [WARNING] Screen logger not set. Ahh, you want to call MessageHandler.setScreenLogger(Logger) somewhere in your code. There's some points in the maintenance branch's codebase which don't have access to the logger you give to Driver. In these cases the code logs via the static methods on MessageHandler. Note that because MessageHandler is completely (IIRC) static, you only have to set it once. Also, the logger you give it could be used concurrently. Anyway, thanks a lot No problem, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: avalon-framework lib in distribution
Hi Jens, I built avalon-framework-cvs-20020315.jar from the Framework codebase in CVS (pulled on the date of the jar file) because at the time, the current release was too out of date. Unfortunately, I think there still hasn't been another release yet. Jens Kühnberger wrote: java.lang.NoClassDefFoundError: org/apache/avalon/framework/logger/ConsoleLogger [snip] when I'm using the avalon-framwork-4.1.2.jar. You'll get the NoClassDefFoundError when using avalon-framwork-4.1.2.jar because it doesn't contain the afore-mentioned up-to-date code. The problem with the avalon-framework-cvs-20020315.jar that comes with the fop-0.20.4-bin.tar.gz is, that it doesn't have the org.apache.avalon.framework.logger.Log4JLogger class. The Log4JLogger probably wasn't built becuase Log4J would not have been found when I was compiling the Framework codebase. The solution would be to pull the Framework source code, make sure Log4J is on your CLASSPATH, and build it. Use the resulting jar instead of both avalon-framework-cvs-20020315.jar and avalon-framwork-4.1.2.jar and you should be fine. HTH, /mike -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Image Source with FOPServlet
Steiner, Priska wrote: I would like to make a report with an image in it. When I render the xml and the xsl with the image source, with FOP 0.20.4 out a commandline, it works fine. But I have to render it, with exactly the same files in a FOPServlet. There it gives me a NullPointerException. Taking a wild stab in the dark (you'd probably want to provide a stack trace for a more accurate guess.. :), the generated file URL isn't valid. Your file URL will end up looking like: file:c:\xsl\bild_1200011229.jpg There are a few problems with this. First, the URL doesn't have a leading '/', or an authority part. Eg: file:///c:\xsl\bild_1200011229.jpg or at least: file:/c:\xsl\bild_1200011229.jpg Next, the ':' character the 'c' is (IIRC) invalid for a URL at that point, and either needs to be escaped or replaced with something valid (a '|' is usally used) file:/c|\xsl\bild_1200011229.jpg or file:///c%3A\xsl\bild_1200011229.jpg Lastly, you've used '\' as the path separator, not '/', which is also invalid in a URL. So, in the end, the URL shoulddl look like: file:///c|/xsl/bild_1200011229.jpg Either you'll want to modify your XML to use a valid URL path component and your XSLT to use prepend file:/// instead of just file:, or modify your XSLT to fixup the Windows file path, turning it into a valid URL path component as part of the transformation. I don't know how lax the JRE on Windows is WRT strict parsing of file URLs, but if you fix up all of the above, at least you'll know you're referencing your image correctly. :) HTH, /mike -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Image Cache issue - Latest Release after 0.20.3
Hi Rishi, Athalye, Rishi wrote: We are using fop 0.20.3 and it appears to be working fine for our purpose except for 1 major point. Caching of Images. Yep, I was going to have a look at improving this, but haven't had the time lately. I did read about some people coming up with a solution for Image Caching and also that it's a known issue. There isn't a fix for it AFAIK, but you can turn off caching altogether with a recompile. Comment out line 196 in FopImageFactory on the maintenance branch like so: // m_urlMap.put(href, imageInstance); and recompile FOP. Note that this will slow down rendering and increase short-term memory usage if you use the same image multiple times in a document. It will get worse the more you use the same image. Unless someone comes up with an actual fix (or applies an existing fix if there is one out there in the wild) sometime real soon now, then this will still be a problem in the next release. Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
[patch] fix for background image tiling
Guys,
The attached patch implements PDFRenderer.drawImageClipped() properly,
so the right-most and bottom-most images of a tiled image background are
now clipped, rather than being scaled or overrun. It also removes a bit
of System.out cruft I left in the previous image bg patch.
Can a comitter please have a look at the patch and commit if happy.
Cheers,
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
? FopImageFactory.patch
? background-image_0.01.patch
? background-image_0.02.patch
? background-image_0.03.patch
? background-image_0.04.patch
? bg-renderer.patch
? dist-bin
? dist-src
? fop-background-image-0.03-bin.tar.gz
? fop-background-image-0.03-bin.zip
? fop-background-image-0.03-src.tar.gz
? fop-background-image-0.03-src.zip
? table-and-block.fo
? table-and-block.pdf
? test-config.xml
? test.fo
? test.pcl
? test.pdf
? test.ps
? test.txt
? docs/html-docs
? docs/xml-docs/book.xml
Index: src/org/apache/fop/layout/BodyRegionArea.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/layout/BodyRegionArea.java,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 BodyRegionArea.java
--- src/org/apache/fop/layout/BodyRegionArea.java 23 Apr 2002 22:26:10 -
1.3.2.1
+++ src/org/apache/fop/layout/BodyRegionArea.java 3 May 2002 08:08:52 -
@@ -25,11 +25,6 @@
}
public BodyAreaContainer makeBodyAreaContainer() {
- System.out.println( +++ Constructing new BodyAreaContainer:);
- System.out.println( - x : + xPosition);
- System.out.println( - y : + yPosition);
- System.out.println( - allocW: + width);
- System.out.println( - maxH : + height);
BodyAreaContainer area =
new BodyAreaContainer(null, xPosition, yPosition, width,
height, Position.ABSOLUTE, columnCount,
Index: src/org/apache/fop/render/AbstractRenderer.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 AbstractRenderer.java
--- src/org/apache/fop/render/AbstractRenderer.java 23 Apr 2002 22:26:58 -
1.4.2.2
+++ src/org/apache/fop/render/AbstractRenderer.java 3 May 2002 08:08:52 -
@@ -71,10 +71,6 @@
* @param h the height in millipoints
*/
protected void doBackground(Area area, int x, int y, int w, int h) {
- System.out.println(Doing background: + area);
- System.out.println( x: + x + y: + y);
- System.out.println( w: + w + h: + h);
-
if (h == 0 || w == 0)
return;
Index: src/org/apache/fop/render/pdf/PDFRenderer.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
retrieving revision 1.91.2.2
diff -u -r1.91.2.2 PDFRenderer.java
--- src/org/apache/fop/render/pdf/PDFRenderer.java 23 Apr 2002 22:33:39 -
1.91.2.2
+++ src/org/apache/fop/render/pdf/PDFRenderer.java 3 May 2002 08:08:52 -
@@ -323,18 +323,41 @@
FopImage image,
FontState fs) {
- PDFRectangle clip = new PDFRectangle(clipX / 1000,
-clipY / 1000,
-(clipX + clipW) / 1000,
-(clipY + clipW) / 1000);
+ float cx1 = ((float)x) / 1000f;
+ float cy1 = ((float)y - clipH) / 1000f;
+
+ float cx2 = ((float)x + clipW) / 1000f;
+ float cy2 = ((float)y) / 1000f;
+
+ int imgX = x - clipX;
+ int imgY = y - clipY;
+
+ int imgW;
+ int imgH;
+ try {
+ // XXX: do correct unit conversion here..
+ imgW = image.getWidth() * 1000;
+ imgH = image.getHeight() * 1000;
+ }
+ catch (FopImageException fie) {
+ log.error(Error obtaining image width and height, fie);
+ return;
+ }
if (image instanceof SVGImage) {
try {
closeText();
SVGDocument svg = ((SVGImage)image).getSVGDocument();
- currentStream.add(ET\nq\n);
- renderSVGDocument(svg, x, y, fs);
+ currentStream.add(ET\nq\n +
+ // clipping
+ cx1 + + cy1 + m\n +
+ cx2 + + cy1 + l\n +
+ cx2 + + cy2 + l\n +
+ cx1 + + cy2 + l\n +
+ W\n +
+ n\n);
+ renderSVGDocument(svg, imgX, imgY, fs
Re: background-image patch v0.03 in CVS
Enrico Schnepel wrote: I've attached the minimal test case. It can't be a smaller .fo file - only a table with nothing in it and a block - that's all. Hmm, I'm not seeing that error.. with or without the table and paragraph. Have you tried updating from CVS and recompiling recently? -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: inital background-image patch
Arved Sandstrom wrote: Yeah, I rechecked the prose carefully and I didn't spot anything either. Okay, if no one objects, I'll leave the region area background implementation in. Slight segue: I was up at the cottage this weekend opening up, and lots of evenings this week are hosed also, but tomorrow evening is open, so I'll quickly apply your patch, build, run it, and commit it if that all works out, which I don't doubt. Cheers! For the occasion, I've released v0.03 of the patch, please have a look at this one instead. 8) The changes are: - backgrounds are now supported on all region areas, including fo:region-body. - PSRenderer now positions backgrounds properly. - I've either tested or at least code-audited all of the Renderer impls, and they should all work as well as they did previously. Still to do (but can be done after the patch has landed): - fix PDFRenderer.drawImageCropped() so it works properly. - implement drawImageFoo() methods in the other renderers. - refactor renderImageArea() in the other renderers - sort out the addRectFoo() negative height mess (is this worth doing?) Patch, binaries: http://web.vee.net/fop/background-image_0.03.patch http://web.vee.net/fop/fop-background-image-0.03-bin.tar.gz http://web.vee.net/fop/fop-background-image-0.03-bin.zip /mike -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: inital background-image patch
Softgui wrote: I've tryed this with PDF and it seems to work well, but I coudn't find a way to have a complete page background (with no resize). The back ground is only under the text blocks. As Arved said before, the only way to do this would be to put a background on the page's fo:region-body and set the page-master margin to be 0 so the body region covers the entire page. This is ugly, but should work with v0.03 of the background-image patch. Have you, or some one else have some background image samples ? If not I can work on it if you want (like a new example directory). I've been using a terribly munged version of docs/examples/fo/images.fo for testing the background-image stuff, which I'd be terribly emabrrased to show anyone.. 8) If you want to put a few good examples together which use background-color, background-image and background-repeat with various combinations of transparent and non-transparent images, that would be cool. Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: inital background-image patch
Arved Sandstrom wrote: I will definitely check it out. Thanks Arved. I've put v0.02 of the patch up. This fixes one small bug when tiling background images, but more importantly I've removed the changes to fix addRectFoo() wanting a negative height. This simpilifies the patch and greatly reduces the scope of the changes. Let me know what you think. I'm going to start on getting the other renderers working next. http://web.vee.net/fop/background-image_0.02.patch http://web.vee.net/fop/fop-background-image-0.02-bin.tar.gz http://web.vee.net/fop/fop-background-image-0.02-bin.zip Cheers. Mike, -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
inital background-image patch
Guys, An initial maintenance-branch patch for background-image and background-repeat property support can be found at: http://web.vee.net/fop/background-image_0.01.patch This patch is *not* ready to get comitted to the repository, rather I'm posting it to a) get some help testing it, b) get feedback about the nature and scope of the changes I've made. So please, have a look at it, try it out, and send me as much feedback as possible, especially on: - The API changes to AbstractRenderer. - Changing addRectFoo() to only ever expect +ve heights. - Seeing if the MIF and TXT renderers still work as advertised (but without bg image support). To support background images, the following has changed: - Implemented the background-image and background-repeat properties. - PropertyManager resolves the bg image source to a FopImage when first retreiving an instance of BackgroundProps. - Areas now store an instance of BackgroundProps rather than just the background color. - AbstractRenderer has a concrete doBackground() method, and abstract drawImageFoo() methods to support doBackground(), renderImageArea() and possibly others. - PDFRenderer and PrintRenderer have been modified to use doBackground() and provide concrete implementations of the drawImageFoo() methods. As a direct result: - PDFRenderer.renderImageArea() has been generalized and moved into AbstractRenderer. - Start of support for working region-foo backgrounds has been added - The addRectFoo() methods should now expect only +ve heights Stuff that isn't working: - All renderers other than PDFRenderer, and possibly the MIF renderer and TXTRenderer. - Image cropping, so on a tiled background, the last row and column of images are scaled rather than cropped if the width/height if the content area isn't an exact multiple of the image's width/height. Binaries for testing can be found at: http://web.vee.net/fop/fop-background-image-0.01-bin.tar.gz http://web.vee.net/fop/fop-background-image-0.01-bin.zip Please *do not* use this binary in a production system. Thanks (especially for reading this far ;), Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
bugzilla usage
Guys, How does FOP use Bugzilla? Aside from a bug reporting tool, I mean. 8) I'm quite familiar with the ins-and-outs of Bugzilla, after using it extensively at work and for Mozilla, but is it used formally? I.e. is it normal for developers working on a bug to assign it to themselves (as I just did for bug 5180)? Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Logging work: patch for the trunk
Guys,
Attached is a patch for the trunk to convert it over to using Avalon
Loggers, instead of the Logkit. This is AFAIK the last of the conversion
work required.
In addition to applying the patch, lib/avalon-framework-cvs-20020315.jar
and it's license file will need to be added (a copy exists in the
maintanence branch) and lib/logkit-1.0.LICENSE.txt and
lib/logkit-1.0.jar must be removed.
Can someone please review the patch and commit when they are happy?
Thanks,
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
Index: build.bat
===
RCS file: /home/cvspublic/xml-fop/build.bat,v
retrieving revision 1.15
diff -u -r1.15 build.bat
--- build.bat 30 Oct 2001 07:21:33 - 1.15
+++ build.bat 11 Apr 2002 08:48:22 -
@@ -7,7 +7,7 @@
set LIBDIR=lib
set
LOCALCLASSPATH=%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\classes.zip;%LIBDIR%\ant.jar;%LIBDIR%\batik.jar;%LIBDIR%\buildtools.jar;%LIBDIR%\xerces-1.4.3.jar;%LIBDIR%\xalan-2.2D11.jar
-set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jimi-1.0.jar;%LIBDIR%\logkit-1.0.jar
+set
+LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jimi-1.0.jar;%LIBDIR%\avalon-framework-cvs-20020315.jar
set ANT_HOME=%LIBDIR%
Index: build.sh
===
RCS file: /home/cvspublic/xml-fop/build.sh,v
retrieving revision 1.16
diff -u -r1.16 build.sh
--- build.sh30 Oct 2001 07:21:33 - 1.16
+++ build.sh11 Apr 2002 08:48:22 -
@@ -14,7 +14,7 @@
fi
LIBDIR=lib
LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xerces-1.4.3.jar:$LIBDIR/xalan-2.2D11.jar
-LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/jimi-1.0.jar:$LIBDIR/logkit-1.0.jar
+LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/jimi-1.0.jar:$LIBDIR/avalon-framework-cvs-20020315.jar
ANT_HOME=$LIBDIR
Index: build.xml
===
RCS file: /home/cvspublic/xml-fop/build.xml,v
retrieving revision 1.52
diff -u -r1.52 build.xml
--- build.xml 18 Mar 2002 08:58:05 - 1.52
+++ build.xml 11 Apr 2002 08:48:23 -
@@ -128,7 +128,7 @@
include name=lib/xerces-1.4.3.jar/
include name=lib/xalan-2.2D11.jar/
include name=lib/batik.jar/
- include name=lib/logkit-1.0.jar/
+ include name=lib/avalon-framework-cvs-20020315.jar/
include name=lib/jimi*/
/fileset
@@ -275,7 +275,7 @@
taskdef name=runTest classname=org.apache.fop.tools.anttasks.RunTest/
property name=main.class value=org.apache.fop.apps.Fop/
-property name=runtime.classpath value=lib/xerces-1.4.3.jar
lib/xalan-2.2D11.jar lib/batik.jar lib/jimi-1.0.jar lib/logkit-1.0.jar/
+property name=runtime.classpath value=lib/xerces-1.4.3.jar
+lib/xalan-2.2D11.jar lib/batik.jar lib/jimi-1.0.jar
+lib/avalon-framework-cvs-20020315.jar/
filter filtersfile=${build.src}/codegen/filter/
Index: fop.bat
===
RCS file: /home/cvspublic/xml-fop/fop.bat,v
retrieving revision 1.4
diff -u -r1.4 fop.bat
--- fop.bat 20 Aug 2001 21:11:02 - 1.4
+++ fop.bat 11 Apr 2002 08:48:23 -
@@ -1 +1 @@
-java -cp
build\fop.jar;lib\batik.jar;lib\xalan-2.0.0.jar;lib\xerces-1.2.3.jar;lib\avalon-framework-4.0.jar;lib\logkit-1.0b4.jar;lib\jimi-1.0.jar
org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
+java -cp
+build\fop.jar;lib\batik.jar;lib\xalan-2.0.0.jar;lib\xerces-1.2.3.jar;lib\avalon-framework-4.0.jar;lib\avalon-framework-cvs-20020315.jar;lib\jimi-1.0.jar
+ org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
Index: docs/xml-docs/fop/embedding.xml
===
RCS file: /home/cvspublic/xml-fop/docs/xml-docs/fop/embedding.xml,v
retrieving revision 1.16
diff -u -r1.16 embedding.xml
--- docs/xml-docs/fop/embedding.xml 17 Mar 2002 17:43:55 - 1.16
+++ docs/xml-docs/fop/embedding.xml 11 Apr 2002 08:48:23 -
@@ -37,6 +37,18 @@
driver.setRenderer(RENDER_PDF);
driver.run();]]/source
+ pYou also need to set up logging. Global logging for all FOP
+processes is managed by MessageHandler. Per-instance logging
+is handled by Driver. You want to set both using an implementation
+of org.apache.avalon.framework.logger.Logger. See
+jump href=http://jakarta.apache.org/avalon/framework/;Jakarta
+Avalon Framework/jump for more information.
+ /p
+source![CDATA[
+Logger logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
+MessageHandler.setScreenLogger(logger);
+driver.setLogger(logger);]]/source
+
pTo setup the user config file you can do the following
/p
source![CDATA[
Index: src/org/apache/fop/apps/CommandLineOptions.java
implementing background-image (bug 5180)
Guys, I need to be able to use the background-image property, which is not yet implemented http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5180. Is anyone working on this at the moment? If not, I'm happy to make an attempt at it. Is there anything I should know about implementing properties in FOP, or this one in general, that I wouldn't pick up from looking at the existing code? Thanks, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: CVS branches
Keiron Liddle wrote: Confusion abounds! It does indeed. 8) The trunk is also known as: HEAD, MAIN, main, development, redesign or even cvs update -A or cvs update -rHEAD Okay, thanks for clearing that up. My confusion arose from the fact that ViewCVS (which is used by cvs.apache.org) lists MAIN as a FOP branch. I looked at another ViewCVS installation, and that also lists MAIN as a branch. So I guess it's just a facet of ViewCVS. Apologies for the static. Michael. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS branches
Christian Geisert wrote: I assumend MAIN and HEAD are equivalent ... (Maybe someone can explain this to me ;-) Not in FOP.. 8) If you checkout FOP without a given branch you get the main development branch (aka redesign). Yeah, that's the case. This is usually called the trunk, and is a special case branch. It has the symbolic name HEAD, although you don't want to use that when checking it out. FOP actually has a branch called MAIN, separate to the trunk (HEAD). Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
CVS branches
Guys, Sorry to reshash what is probably an old and tired subject, but I've gotten some conflicting advice as to what CVS branch is used for what. If anyone could help fill in the blanks and correct the errors, I'd appreciate it. 8) MAIN - FOP redesign / new-design branch. This is where dev for for the next main iteration of FOP is done. HEAD - I assume v0.21 and latter versions will stem from this branch at some stage, up until the work on the MAIN branch lands on the trunk. fop-0_20_2-maintain - the v0.20.x maintanence branch. Further releases in the v0.20.x series (and others?) are made from this branch. Thanks, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Logging work: examples compilation fixes
The attached patch fixes the embedding examples so they compile again.
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
Index: docs/examples/embedding/FopServlet.java
===
RCS file: /home/cvspublic/xml-fop/docs/examples/embedding/FopServlet.java,v
retrieving revision 1.4.2.1
diff -u -r1.4.2.1 FopServlet.java
--- docs/examples/embedding/FopServlet.java 1 Mar 2002 12:44:39 - 1.4.2.1
+++ docs/examples/embedding/FopServlet.java 19 Mar 2002 04:19:09 -
@@ -16,8 +16,10 @@
import org.apache.fop.apps.Driver;
import org.apache.fop.apps.Version;
import org.apache.fop.apps.XSLTInputHandler;
+import org.apache.fop.messaging.MessageHandler;
-import org.apache.log.*;
+import org.apache.avalon.framework.logger.ConsoleLogger;
+import org.apache.avalon.framework.logger.Logger;
/**
* Example servlet to generate a PDF from a servlet.
@@ -32,14 +34,13 @@
* - servlet_2_2.jar
* - fop.jar
* - sax api
- * - logkit jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
*
* Running: you will need in the WEB-INF/lib/ directory:
* - fop.jar
* - batik.jar
- * - avalon-framework-4.0.jar
- * - logkit-1.0.jar
* - xalan-2.0.0.jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
*/
public class FopServlet extends HttpServlet {
public static final String FO_REQUEST_PARAM = fo;
@@ -50,9 +51,8 @@
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException {
if(log == null) {
-Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
-log = hierarchy.getLoggerFor(fop);
-log.setPriority(Priority.WARN);
+log = new ConsoleLogger(ConsoleLogger.LEVEL_WARN);
+MessageHandler.setScreenLogger(log);
}
try {
String foParam = request.getParameter(FO_REQUEST_PARAM);
Index: docs/examples/embedding/FopPrintServlet.java
===
RCS file: /home/cvspublic/xml-fop/docs/examples/embedding/Attic/FopPrintServlet.java,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 FopPrintServlet.java
--- docs/examples/embedding/FopPrintServlet.java1 Mar 2002 12:44:39 -
1.1.2.2
+++ docs/examples/embedding/FopPrintServlet.java19 Mar 2002 04:19:09 -
@@ -21,10 +21,12 @@
import org.apache.fop.layout.Page;
import org.apache.fop.apps.Version;
import org.apache.fop.apps.XSLTInputHandler;
+import org.apache.fop.messaging.MessageHandler;
import org.apache.fop.render.awt.AWTRenderer ;
-import org.apache.log.*;
+import org.apache.avalon.framework.logger.ConsoleLogger;
+import org.apache.avalon.framework.logger.Logger;
/**
* Example servlet to generate a fop printout from a servlet.
@@ -40,13 +42,12 @@
* - servlet_2_2.jar
* - fop.jar
* - sax api
- * - logkit jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
*
* Running: you will need in the WEB-INF/lib/ directory:
* - fop.jar
* - batik.jar
- * - avalon-framework-4.0.jar
- * - logkit-1.0.jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
* - xalan-2.0.0.jar
*/
@@ -62,9 +63,8 @@
{
if (log == null)
{
-Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
-log = hierarchy.getLoggerFor(fop);
-log.setPriority(Priority.WARN);
+log = new ConsoleLogger(ConsoleLogger.LEVEL_WARN);
+MessageHandler.setScreenLogger(log);
}
try
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Logging work: MessageHandler patch
Michael Gratton wrote:
Attached is a patch (for the 'fop-0_20_2-maintain' branch) for
MessageHandler
There was a problem with MessageHandler.error() in that patch. The
attached patch fixes that and makes MessageHandler.log() a bit more
readable. It also includes a fix for the outstanding
ToBeImplementedProperty problem - by using MessageHandler.
Note that the document patch on the previous message is still valid.
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
Index: src/org/apache/fop/messaging/MessageHandler.java
===
RCS file:
/home/cvspublic/xml-fop/src/org/apache/fop/messaging/Attic/MessageHandler.java,v
retrieving revision 1.6.2.1
diff -u -r1.6.2.1 MessageHandler.java
--- src/org/apache/fop/messaging/MessageHandler.java17 Mar 2002 23:37:07 -
1.6.2.1
+++ src/org/apache/fop/messaging/MessageHandler.java19 Mar 2002 04:46:04 -
@@ -48,6 +48,7 @@
public static final int EVENT = 2;
public static final int NONE = 3;// this should always be the last method
+private static Logger logger = null;
private static String logfileName = fop.log;
private static PrintWriter writer;
private static int outputMethod = SCREEN;
@@ -81,47 +82,47 @@
}
}
-// temp workaround
-private static Logger logger = null;
-
/**
* informs the user of the message
* @param message the message for the user
*/
public static void log(String message) {
-if (!quiet) {
-if(logger == null) {
-logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
-}
-setMessage(message);
-switch (outputMethod) {
-case SCREEN:
-logger.debug(getMessage());
-break;
-case FILE:
-if (fileOpened) {
-writer.print(getMessage());
-writer.flush();
-} else {
-openFile();
-writer.print(getMessage());
-writer.flush();
-}
-break;
-case EVENT:
-setMessage(message);
-Enumeration enum = listeners.elements();
-while (enum.hasMoreElements()) {
-((MessageListener)enum.nextElement()).processMessage(new
MessageEvent(getMessage()));
-}
-break;
-case NONE:
-// do nothing
-break;
-default:
-logger.debug(message);
-}
-}
+if (quiet)
+ return;
+
+ if (logger == null) {
+ logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
+ logger.warn(Screen logger not set.);
+ }
+
+ setMessage(message);
+ switch (outputMethod) {
+ case SCREEN:
+ logger.debug(getMessage());
+ break;
+ case FILE:
+ if (fileOpened) {
+ writer.print(getMessage());
+ writer.flush();
+ } else {
+ openFile();
+ writer.print(getMessage());
+ writer.flush();
+ }
+ break;
+ case EVENT:
+ setMessage(message);
+ Enumeration enum = listeners.elements();
+ while (enum.hasMoreElements()) {
+ ((MessageListener)enum.nextElement()).processMessage(new
+MessageEvent(getMessage()));
+ }
+ break;
+ case NONE:
+ // do nothing
+ break;
+ default:
+ logger.debug(message);
+ }
}
/**
@@ -138,9 +139,11 @@
*/
public static void error(String errorMessage) {
-if(logger == null) {
-logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
-}
+ if (logger == null) {
+ logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
+ logger.warn(Screen logger not set.);
+ }
+
setMessage(errorMessage);
switch (outputMethod) {
case SCREEN:
@@ -195,6 +198,16 @@
*/
public static void removeListener(MessageListener listener) {
listeners.removeElement(listener);
+}
+
+/**
+ * Sets the Logger used for the screen output method.
+ * @param newLogger a logger for screen output. This may not be null.
+ */
+public static void setScreenLogger(Logger newLogger) {
+ if (newLogger == null)
+ throw new NullPointerException();
+ logger = newLogger;
}
/**
Index: src/org/apache/fop/apps/CommandLineOptions.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision
Re: Using Avalon/Logkit
Hey Jeremias,
Jeremias Maerki wrote:
I can help you with implementing or documenting, whatever you want.
Thanks for the offer, and thanks for the pointers. It's too late for me
start this now, I'll do it at work tomorrow (about 16hrs away) - gotta
love getting paid to work on OS projects.. ;)
I'm 100% confident I can sort this myself - it's exacly the same work
involved as the previous patch I posted, but if you're on hand to answer
any further questions that may arise, that would be useful.
WRT the last point, I'll make Driver implement LogEnabled and drop
Loggable. Given that (according to the javadocs on the Avalon web site)
LogEnabled exposes enableLogging(), not setLogger(), and does not
provide an analog for getLogger(), I'd suggest leaving any classes which
implement {get|set}Loggable() alone for now.
Sound okay?
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
Jeremias Maerki wrote: I'd extend Driver from AbstractLogEnabled and overwrite getLogger() as done in the current version (maintbranch). Cool, will do. Out of curiosity, what was the name of that branch? Keiron mentioned elsewhere that I'd probably want to patch both branches - one is obviously going to be HEAD, the other I assumed was MAIN, but I'm not so sure now.. Anyway, a preliminary, but fully functional patch against the fop-0_20_3 branch can be found here: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. I just need to port it to the two other branches, and deal with both MessageHandler and ToBeImplementedProperty, then it is ready to land. I'll fix these things up sometime in the next few days.. Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
Hey Jeremias, Jeremias Maerki wrote: Right, I think we agree here. Cool. I'm exactly proposing this. I suggest you really have a look at Avalon. Avalon is very far from being another large library. Avalon Framework is 46K, LogKit is about 52K. Is that large? Okay, my two large libraries remark was off-centre, but you really need to consider those who, for whatever reason, simply *can't* use Avalon. The reasons may be technical, political or otherwise, but if FOP forces people to use Avalon, then you will end up having people who won't use FOP because of it. I'd love to have the time to get to know Avalon, but I just don't. In addition, the there is no way the particular project here at work I want to embed FOP in is going to use Avalon. Period. If the dependency on Avalon can't be broken, then there's very little chance FOP will be used for this project. Which I'll find very dissapointing, because I'm a big fan of FOP. org.apache.avalon.framework.logger.Logger is almost exactly what you did in your proposal, except that you introduce yet another API, Okay, in it's defence, the LoggingHandler API is very small, being one interface large. The LogkitLoggingHandler class provides a transparent wrapper for using Logkit and Avalon with FOP. For existing applications, such as the command line app, it took (IIRC) one extra line and changing three others to use the LoggingHandler mechanism, and it still uses Logkit for the logging. If you want to use your own logger, then just wrap it in a LogkitLoggingHandler and away you go. The amount of additional work required to use the new interface is absolutely minimal, and it will still work with Avalon, most likely by changing one single line of code or configuration. We're talking about reusing mature code. And that sometimes means we have one more jar to include. I'm not talking about throwing it all away - you can still use all of that existing code if you want. And sometimes one more jar is one too many. I'm disappointed that you're shooting against something you don't know. I'll be the first to admit that I'm not familiar with Avalon, but I do know I can't use it every project, even if I had the time to learn about it, and I also know that if you start making core FOP functionality depend on external services such as Avalon, a lot of embedders will go elsewehre. Seems like we agree here. What I don't understand is how you can agree with using something like ErrorHandler but be against using a LoggingHandler, which works *precisely* in the same way. It's the *exact* same mechanism, but for logging. If it still works with Avalon and Logkit, and works for embedders, how can you lose from such a win-win situation? Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
want to use Mozilla's great rendering engine - Gecko - to provide HTML rendering capbilities for their application. Gecko uses internally many Mozilla technologies and is wrapped by others for the actual browser itself, but those developers just want to Gecko, they don't want to know and don't care about XPCOM, or XUL, or libpr0n, just so long at Gecko does it's job. Mozilla's developers recognised this, have built Mozilla accordingly, and so now you can embed Mozilla in C/C++ and Java applications without knowing or caring about the underlying technologies used. Hell, there's even an ActiveX wrapper for Gecko so you can embed it in IE. As a result, many developers have embedded Gecko, and everyone wins. If these developers had had to learn XPCOM, XUL, XBL and everything else, then there's little chance they would have embedded Gecko, and everyone loses. Note that developers could choose to use some of these other technologies, but in most cases, they didn't. FOP is in the same boat. If FOP is going to be widely embedded, it needs to expose a core framework-independent and architecture-independent interface. Look, does anyone else out there agree or disagree with me? Am I flogging a dead horse? Barking up the wrong tree? Committers, am I wasting my time here? Thanks, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
Keiron Liddle wrote: If you submit a patch for this it will be committed before you know it! Excellent! No-one else has mentioned working on it so go ahead. It will probably need to be done on both branches but do whatever you want to. Right, I'll get onto it, then. Jeremias mentioned LogEnabled is replacing Loggable, is there any concensus about moving Driver over to the new interface, making it implement both, or just leaving it as-is for now? I'd suggest moving it over, if not, then implementing both. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
Jeremias Maerki wrote: Logging is one thing. Error handling (like layout problems, image that can't be found etc.) is another. Right As much as it at the moment. Obviously, errors need to be reported, and the most convenient way to do that is via a logging mechanism. In addition, it's often useful if there's some sort of callback mechanism so that the application, whether that be Driver or some code embedding FOP, can decide how to continue, *if* it should continue, and potentially, how to log the error. Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is a convenient and flexible way to go. Logging: I'd go for the Avalon Logger interface which lets us freely choose the logging backend. We can even use the new ConsoleLogger or even NullLogger. :-) Fair enough, but I maintain that it's still too much work for embedders. It is a right pain to have to have to include two more large libraries (Avalon and Logkit) with your application just to let FOP do logging, and it's too much functionality if your application has it's own logging mechanism already. I'd suggest it would be a poor move to lock FOP into using one particular logging mechanism, especially when there are many alternatives out there: Log4J, 1.4's native logging mechanism, and all the existing, custom jobs, many of which have rabid supporters who won't use anything else. 8) Error handling: We had a short discussion back in November. Doing that in the user agent sounds good (it's the obvious place) although I can't fully figure out yet if this solves everything we need. I agreee, FOP needs something like the ProblemListener you suggested in the thread above. As I suggested in an earlier email WRT logging, I think the UA is the right place to get an instance of an ErrorHandler/ProblemListener, but should not itself be responsible for that functionality. What should happen (IMHO) is similar to the SAX model: The application (Driver, or the embedding app) optionally supplies an instance of ErrorHandler. If none is supplied, a default instance is used which provides resonable default behavior (something like letting warnings pass but throwing exceptions for errors). When an error condition arises, the code should obtain that instance of ErrorHandler from the UA or potentially elsewhere (but it should not just instantiate it's own) and invoke the appropriate method on the handler, passing it an appropriate exception object. The implementation then decides if it is worth throwing that exception, and can do anything else it considers worthwhile as well. Again, with this sort of mechansim, you get flexibility and control, and it is very much embedding-friendly. Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
LoggingHandler patch [was: Using Avalon/Logkit]
Guys,
To further to my suggestions about using an interface for logging in
core FOP components, I've produced a working implementation of my
suggestion. After a precursory test using the command line, the changes
seem to work fine.
The patch, for the fop-0_20_3 branch in CVS, and the two additional
required source files are available at:
http://web.vee.net/fop/LoggingHandlerImpl-2002031300.jar
The two added files are src/org/apache/fop/apps/LoggingHandler.java and
src/org/apache/fop/apps/LogkitLoggingHandler.java. The former is the
LoggingHandler interface, which has replaced any use of
org.apache.log.Logger in core FOP code. The latter is an implementation
of LoggingHandler which uses Logkit and is Loggable (for Avalon).
I've identified three applications which use assume the use of Logkit
for logging: The command line app, the FOP task for Ant and
TestConverter. All three have been modified to use LogkitLoggingHandler
and hence function in the exact same fashion as before. In addition, if
no LoggingHandler is explicitly set on Driver, it by default uses an
instance of LogkitLoggingHandler, again to make it behave the same as
before.
Embedders who do not wish to use Logkit for logging can write their own
implementation of LoggingHandler and call Driver.setLogger() prior
invoking Driver.render().
There are three issues which need to be addressed before I would
consider this code ready to commit:
- Is the Loggable implementation of LogkitLoggingHandler sufficient
for Avalon? Not really knowing how Avalon works, I'm not sure if
implementing Loggable on LogkitLoggingHandler is sufficient, or will an
AvalonDriver subclass of Driver be needed which translates between
logging objects be required? Can any Avalon gurus comment on this?
- MessageHandler's use of Logger for screen output needs to be fixed.
This will probably require a setLoggingHandler() method to be added, and
ensuring it gets called prior to MessageHandler getting invoked.
- ToBeImplementedProperty grabs a Logger out of thin air, this should
probably use MessageHandler or just throw an exception (as outlined in
the comments for that class in the patch).
Outstanding, non-essential work includes:
- Perhaps renaming {get|set}Logger() on Renderer and similar classes
to {get|set}LoggingHandler()
- Adding optional implementations of LoggingHandler for Log4J, 1.4's
logging mechanism, and any others.
Please have a look at the patch, try it out applied to the fop-0_20_3
branch and let me know if you have any suggestions. I'll fix up the
three issues above sometime in the next few days and post a new patch.
Provided it all works well, would anyone mind having these changes
committed to the tree?
Thanks,
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using Avalon/Logkit
Guys, I've just encountered this issue, so apologies for barging in late.. Jeremias Maerki wrote: Joerg Pietschmann wrote: In order to clarify issues: I have to use FOP in an environment which already provides logging, configuration management and life cycle management. I don't want to look into another log file. I don't want to write more config files. I'm in the exact same boat here. We'd like to embed FOP but the configuration, management and logging environment we already have is more than sufficient without using another on top. It is a requirement of the project I'm on that all configuration is done via the central configuration mechanism, and all logging is to the project's logger. There's zero chance of using Avalon instead, and if we need to write translation layers between Avalon and what we already have, then embedding FOP will fall into the too hard basket, and we'll need to use somthing else. I'd dearly like to avoid having this happen. I don't want to prevent anyone from providing a FOP embedding using logkit and avalon. I *want* however access to a core which doesn't rely on yet another toolkit for common functionality Ditto. Ok, I think that can be done, even when using Avalon in FOP. You propose (I think) that we could provide an Avalon-Wrapper around FOP, but it could also be the other way around. I'm sure that Avalon will not stand in the way if we provide a simple interface similar to what you proposed. I'm not sure what you mean here, when you say it could be the other way around. Personally, I'd suggest having core FOP logging services taken care of by something akin to org.xml.sax.ErrorHandler. This mechanism works quite nicely. FOP could provide a default implementation which uses Logkit/Avalon and embedders could provide their own. Also, I'm prepared to put my money where my mouth is, so to speak. If people are happy with this approach, I'll gladly implement it over the next few days. I hope this conveys how important I think this issue is. What does everyone say? Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
