Bug report for Fop [2004/04/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly | |
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-18 18:05 --- --- Additional Comments From [EMAIL PROTECTED] 2004-04-18 03:27 --- Glen, Simon, et al. I have a problem with commons-logging. It deliberately leaves the configuration to the user and the underlying logging system. One example of this is in the dynamic setting of log levels. FOP allows a command line (or user configuration) override of the logging level. This code has been the focus of some discussion here. To my way of thinking, such an override is not a configuration issue per se, but extends to be a run-time issue. Perhaps, but not many others appear to be thinking this way. A considerable statement, given all the apps--Tomcat, Axis, Struts, POI, Tapestry, Turbine, etc., etc.--currently using commons-logging as-is. The logging level *is* the prerogative of the user--they decide whether or not they want to see info or debug statements. We don't adjust the log level of the logger, instead we declare the desired level of the message to be displayed. People choose debug level, or info level, and the app stays with that level. When there *are* misbehaving instances, those error messages should be given warn, error, or fatal levels--which guarantees that they will show up in any logger with a debug or an info setting. (i.e., Loggers *will* print out the messages of more severe errors than that of what they are assigned for. It is just that they will not display less severe errors.) Consider the situation in which we wish to allow the logging level to be changed during the lifetime of a single FOP instance; to allow, e.g., an administrator to get more information about a misbehaving instance. Actually, maybe we don't really need to consider it. After all, you think the folks at Tomcat, Turbine, et. al. have never considered that situation--have never needed to? All of them came to same conclusion--even under presumably much more demanding circumstances that FOP would have: the logging level is to be set by the user. Craig McClanahan of Sun is probably the lead developer on Tomcat, Struts, and Commons-Logging, and has been on all three for several years now. If programs not being able to set the logging level was an actual problem, it probably would have been long identified and fixed by now. I believe the C-L team came to the conclusion that would cause more headaches than it solves. I see two logical problems with the argument that the logging requirements of FOP go beyond what might be needed by a servlet container, J2EE server, or Web framework environment--i.e., the motivation for subclassing: (1) FOP primarily runs *on* servlet containers, J2EE servers, and in Web framework. But these servers don't need the ability to set the log level--they're not asking for it--so why do we? (2) Our programmatic cousins--Xalan and Batik--don't even use logging to begin with. (Sometimes I'm unsure if we even need it ourselves!) If it is indeed true that it would be unworkable if FOP cannot set the logging level, would it not follow that Xalan and Batik are immediately DOA because they don't even have loggers? What *is* important for us, however, is that the error messages printed out for the misbehaving instance be detailed enough so the situation can be reproduced. SimpleLog provides this facility, and it is (was?) used in the -d switch processing. No, that's not a runtime option--that's a command-line option that is fixed for the life of the report generation. This option was removed in my last patch, because it was quietly overriding what they have set up in C-L locally, and it was only there for reasons of backward compatibility, which can't be deemed much of an issue anyway given that we've switched the logger. I can't do that if I am using Jdk14Logger, Jdk13LumberjackLogger or Log4JLogger. I don't know whether Log4JLogger supports log level changes, and it doesn't partucularly matter. Jdk14Logger and presumably Jdk13LumberjackLogger do, and it's a very useful facility, even if only to support command line settings. I moved the settings into the fop.bat and fop.sh files in my last (attached) patch. I'm currently unsure how sufficient that is. You do raise a valid point here, however, CL will not allow us to use command line settings to change the logging level. The user needs to read up on the logger that they have chosen, and configure it according to that logger's directions. Logging is truly a configuration item in the Java world. I've taken the issue up on the (overcrowded) jakarta-commons dev
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-18 19:28 --- Glen, On Sat, Apr 17, 2004 at 08:36:13AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-04-17 08:36 --- Simon (and others), For the remaining three issues remaining, please take a look at the patch I just added. 1.) I removed the -debug and -quiet options, because they just cover over the commons-logging settings. Also I'm leery of switching to SimpleLog as a default, seeing the Commons Logging will normally use JDK1.4 logging. Rather than use an API that covers up Commons-Logging functionality (i.e., -d and -q), I would rather have us make it very simple for the user to use/learn the exact commons-logging method, which brings up: I thought that we should retain backward compatibility, but if that is not (yet) the case for the development branch, I am most happy to see these options be dropped. 2.) In fop.bat and fop.sh, (I only tested the former, I'll need someone to check the latter), I created commented-out lines that will allow the user to choose a different logger from the default JDK1.4 and the logging level (the latter, iff they're using SimpleLog). That is very helpful. Frankly I think that users who are not satisfied with the defaults really should study log configuration. But giving them a headstart does not hurt us. 3.) Per your last comment below, on using .info() instead of .debug() in the dumpConfiguration() nee debug() method--I agree, that should be the message level instead because that is what the user is specifically requesting. My patch does this, but without switching to a SimpleLog() to guarantee output. The drawback is that if the user specifically chooses error or fatal, etc., as a level, that will take precedence over setting this field, and as a consequence this information won't be shown. OTOH, the logger that the user specifically chose externally won't be overridden. I suspected the latter was the lesser of two evils, and so went with that. Your thoughts? With the info level, it is OK not to check whether the user has info level enabled; it is the default. I am quite happy with your patch. Peter, I generally agree with Glen's point of view. With this solution we have chosen a good and well-respected logging solution, which has the good sense to act as a middle man who gives the user a choice of logging implementation. Answering queries about logging behaviour and features is no longer on our shoulders. Regards, Simon
cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java
gmazza 2004/04/18 15:39:02
Modified:.fop.bat fop.sh
src/java/org/apache/fop/apps CommandLineOptions.java
Log:
Remaining changes done with Avalon-Commons Logging conversion. (Bug 28237)
Revision ChangesPath
1.19 +16 -1 xml-fop/fop.bat
Index: fop.bat
===
RCS file: /home/cvs/xml-fop/fop.bat,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- fop.bat 31 Mar 2004 10:55:05 - 1.18
+++ fop.bat 18 Apr 2004 22:39:02 - 1.19
@@ -21,6 +21,21 @@
rem and for NT handling to skip to.
:doneStart
+set LOGCHOICE=
+rem The default commons logger for JDK1.4 is JDK1.4Logger.
+rem To use a different logger, uncomment the one desired below
+rem set
LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
+rem set
LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
+rem set
LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
+
+set LOGLEVEL=
+rem Logging levels
+rem Below option is only if you are using SimpleLog instead of the default JDK1.4
Logger.
+rem To set logging levels for JDK 1.4 Logger, edit the
%JAVA_HOME%\JRE\LIB\logging.properties
+rem file instead.
+rem Possible SimpleLog values: trace, debug, info (default), warn,
error, or fatal.
+rem set LOGLEVEL=-Dorg.apache.commons.logging.simplelog.defaultlog=INFO
+
set LIBDIR=%LOCAL_FOP_HOME%lib
set LOCALCLASSPATH=%LOCAL_FOP_HOME%build\fop.jar
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar
@@ -34,5 +49,5 @@
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_core.jar
set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_codec.jar
-java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %FOP_CMD_LINE_ARGS%
+java %LOGCHOICE% %LOGLEVEL% -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop
%FOP_CMD_LINE_ARGS%
1.6 +16 -1 xml-fop/fop.sh
Index: fop.sh
===
RCS file: /home/cvs/xml-fop/fop.sh,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- fop.sh30 Nov 2002 08:54:25 - 1.5
+++ fop.sh18 Apr 2004 22:39:02 - 1.6
@@ -100,5 +100,20 @@
LOCALCLASSPATH=`cygpath --path --windows $LOCALCLASSPATH`
fi
-$JAVACMD -classpath $LOCALCLASSPATH $FOP_OPTS org.apache.fop.apps.Fop $@
+LOGCHOICE=
+# The default commons logger for JDK1.4 is JDK1.4Logger.
+# To use a different logger, uncomment the one desired below
+# LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
+#
LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
+#
LOGCHOICE=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
+
+LOGLEVEL=
+# Logging levels
+# Below option is only if you are using SimpleLog instead of the default JDK1.4
Logger.
+# To set logging levels for JDK 1.4 Logger, edit the
%JAVA_HOME%/JRE/LIB/logging.properties
+# file instead.
+# Possible SimpleLog values: trace, debug, info (default), warn, error,
or fatal.
+# LOGLEVEL=-Dorg.apache.commons.logging.simplelog.defaultlog=INFO
+
+$JAVACMD $LOGCHOICE $LOGLEVEL -classpath $LOCALCLASSPATH $FOP_OPTS
org.apache.fop.apps.Fop $@
1.18 +33 -50xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java
Index: CommandLineOptions.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- CommandLineOptions.java 9 Apr 2004 03:05:40 - 1.17
+++ CommandLineOptions.java 18 Apr 2004 22:39:02 - 1.18
@@ -61,8 +61,6 @@
/* show configuration information */
private Boolean showConfiguration = Boolean.FALSE;
-/* suppress any progress information */
-private Boolean quiet = Boolean.FALSE;
/* for area tree XML output, only down to block area level */
private Boolean suppressLowLevelAreas = Boolean.FALSE;
/* user configuration file */
@@ -132,16 +130,9 @@
*/
private boolean parseOptions(String[] args) throws FOPException {
for (int i = 0; i args.length; i++) {
-if (args[i].equals(-d) || args[i].equals(--full-error-dump)) {
-log = new SimpleLog(FOP);
-((SimpleLog) log).setLevel(SimpleLog.LOG_LEVEL_DEBUG);
-} else if (args[i].equals(-x)
+if (args[i].equals(-x)
|| args[i].equals(--dump-config)) {
showConfiguration = Boolean.TRUE;
-} else if (args[i].equals(-q) || args[i].equals(--quiet)) {
-quiet
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-18 22:41 --- Patch applied. I'm closing Simon's issue here, but Peter's concerns can still be discussed on this bug page or on the FOP-DEV list directly. Glen
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-18 23:19 --- Two related questions: If logging levels are supposed to be set through configuration files, then 1) why did the Sun guys put setLevel() in the API for java.util.logging? 2) why did the commons-logging guys put setLevel() in SimpleLog? You're all individuals Brian Yes! We're all individuals Crowd You're all different Brian Yes! We are all different Crowd I'm not Dissenter Monty Python's Life of Brian
Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
Glen Mazza wrote: proper TR14 line breaking needs a precious character LB property and a whitespace status Darn, should be previous. I'm not sure what you're referring to here--the TR at http://www.unicode.org/unicode/reports/tr14/, doesn't appear to mention a whitepace status or LB property per se. In order to determine whether a line break can be inserted between two non-space characters with optional space chars in between (which would either be left at the end of the line or discarded), the algorithm needs the LB properties of both the characters as well as whether any space was encountered. The line breaking property (those AL etc. stuff) is defined in one of the Unicode data files for each character. Hmmm...not that big a deal to me, but I would be inclined to keep the whitespace removal out of the LayoutManagers, because it is fo:block specific I don't quite understand this argument. Handling space-before is also fo:block specific. Where should this logic be put, then? Note that whitespace handling includes removing spaces around line breaks which are introduced during the layout process. J.Pietschmann
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-19 03:42 --- 1) why did the Sun guys put setLevel() in the API for java.util.logging? 2) why did the commons-logging guys put setLevel() in SimpleLog? You caught me on the first question--I noticed I was in error when I wrote: What they (and Sun, with its 1.4 logger) are telling you--logging is a configuration and not a runtime issue--should carry some weight with you. Sun is *not* telling us this, precisely because they do have a setLevel(). (But that does not necessarily mean they advocate calling programs from switching it--the user could be setting it for his own embedded program.) In the meantime, it may be helpful for you to look at C-L's team's thoughts on having a setLevel() below, and in the last link, a potential workaround as well as Craig McClanahan's concerns with modifying the underlying implementation from C-L: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=102571996601634w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101096333702331w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101097934025726w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101068848405397w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101061362702721w=2 (point 2) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14155 (sample workaround, also Craig's four problems with a setLevel()) Also, to give you a better idea of the usage of C-L, here's a list of the 88 projects currently linking with it: http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html#Project+Dependees Glen
