DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 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.  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.

SimpleLog provides this facility, and it is (was?) used in the -d switch
processing.  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've taken the issue up on the (overcrowded) jakarta-commons dev list, and been
told that it's a configuration issue, and that SimpleLog has the facility
because there is no underlying logger.  I don't see it, but it's not worth
arguing about there, especially as it was suggested that I subclass the relevant
interfaces and classes if I wanted the facility.  That seems to be the way to go.

The alternative is to drop back to the native logger whenever a change of level
is required, which seems to me to rather defeat the purpose.

Simon's original point I think ran counter to this proposal ("create a
hard-coded SimpleLog instance with the appropriate log level set").  Note,
though, that the behaviour of the default common-logging LogFactory is to create
a single log instance *of any given name*.  If we create a log named "FOP" (or
"org.apache.fop" if we are following the 1.4 recommendations), it is not going
to interfere with the logging of any other applications, but the user will
expect to see changes to the level reflected in the Fop log (but see
configuration details below).

If users have set up debugging in the user configuration file, we ought to give
them debug logging.  If there is a conflict with some other setting, it is the
user's responsibility.  If there is a command line switch for debugging, the
requirement is even more definite.

The default logging selection behaviour is quite complex:
Find a LogFactory
  a system property named org.apache.commons.logging.LogFactory
  JDK 1.3 JAR Services Discovery - a resource named
   META-INF/services/org.apache.commons.logging.LogFactory
  properties file commons-logging.properties:
   property org.apache.commons.logging.LogFactory
  else default LogFactory

The default LogFactory looks for:
  configuration attribute org.apache.commons.logging.Log
  else system property org.apache.commons.logging.Log
  else if Log4J available, Log4JLogger
  else if 1.4, Jdk14Logger
  else SimpleLog

I suspect that Jdk13LumberjackLogger might be in there between Jdk14Logger and
SimpleLog.

Whether the LogFactory that is in use is well behaved or not will depend on
configuration details which are deliberately beyond our control, but the JDK and
default LogFactory both guarantee a single instance of a Log of a given name. 
This seems to satisfy one of Simon's difficulties.
"2. The command line options -d and -e are used to configure the Log
   object of the options object. This log is not passed on to driver,
   and thus gets lost."

If users are specifying a logging implementation which does *not* behave in this
way, and in obeying their instructions about, say, debugging, we go over the top
of their entire server logging, they need to fix their instructions to Fop or
use another logger.

I agree with Simon that, in the absence of any specifics, we make no changes to
the inherited logging environment.

"3. Commons logging is also configured by Java system properties. A
   user may configure it to use a certain logging implementation,
   e.g. Log4J. Hard coding a SimpleLog instance goes against
   reasonable expectations of users when we advertise that we use
   commons logging. If a user does nothing he gets the JDK 1.4 logging
   if he runs that version, and SimpleLog otherwise."
Agree.

"SimpleLog logs to stderr; only redirection sends it to a file (and
that is impossible under MSWindows command and cmd shells)."
I didn't realise there was no redirection fa

cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination PageSequence.java

[gmazza]

gmazza  2004/04/17 19:50:46

  Modified:src/java/org/apache/fop/fo/pagination PageSequence.java
  Log:
  Apparent off-by-one error fixed for initial-page-number property:
  
  http://www.w3.org/TR/2003/WD-xsl11-20031217/#initial-page-number
  
  Revision  ChangesPath
  1.20  +1 -1  xml-fop/src/java/org/apache/fop/fo/pagination/PageSequence.java
  
  Index: PageSequence.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/PageSequence.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- PageSequence.java 31 Mar 2004 10:55:06 -  1.19
  +++ PageSequence.java 18 Apr 2004 02:50:46 -  1.20
  @@ -169,7 +169,7 @@
   pageNumberType = EXPLICIT;
   try {
   int pageStart = new Integer(ipnValue).intValue();
  -this.explicitFirstNumber = (pageStart > 0) ? pageStart - 1 : 0;
  +this.explicitFirstNumber = (pageStart > 0) ? pageStart : 1;
   } catch (NumberFormatException nfe) {
   throw new FOPException("\"" + ipnValue
  + "\" is not a valid value for 
initial-page-number");
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop/examples/fo/pagination basic2.fo franklin_alt.fo franklin_rep.fo franklin_rep_max_repeats.fo

[gmazza]

gmazza  2004/04/17 19:01:24

  Modified:examples/fo/pagination basic2.fo franklin_alt.fo
franklin_rep.fo
  Removed: examples/fo/pagination franklin_rep_max_repeats.fo
  Log:
  More consolidation of pagination examples.
  
  Revision  ChangesPath
  1.4   +1 -1  xml-fop/examples/fo/pagination/basic2.fo
  
  Index: basic2.fo
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/pagination/basic2.fo,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- basic2.fo 9 Mar 2004 22:44:35 -   1.3
  +++ basic2.fo 18 Apr 2004 02:01:24 -  1.4
  @@ -48,7 +48,7 @@
 
  +line-height="14pt">
   XML Recommendation - p. 
 
   
  
  
  
  1.5   +0 -13 xml-fop/examples/fo/pagination/franklin_alt.fo
  
  Index: franklin_alt.fo
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/pagination/franklin_alt.fo,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- franklin_alt.fo   22 Mar 2004 23:24:52 -  1.4
  +++ franklin_alt.fo   18 Apr 2004 02:01:24 -  1.5
  @@ -30,25 +30,12 @@
 
   
   
  -  
  -  
  -  
  -  
  -
  -
 
   
 
 
  -  
   
 
   
  
  
  
  1.5   +8 -3  xml-fop/examples/fo/pagination/franklin_rep.fo
  
  Index: franklin_rep.fo
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/pagination/franklin_rep.fo,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- franklin_rep.fo   22 Mar 2004 23:55:54 -  1.4
  +++ franklin_rep.fo   18 Apr 2004 02:01:24 -  1.5
  @@ -19,9 +19,14 @@
   
   
   
  -  
  -  
  +  
  +  
  +  
  +  
   
 
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly

[Glen Mazza]

Hello Joerg, welcome back.

J.Pietschmann wrote:

Glen Mazza wrote:

A further optimization might be to do all this before
the Block is even parsed into FOText and Inline
objects, as many spaces-only objects would end up not
even needing to be created.


This will not account for spaces to be removed around line
breaks.
I'm not sure why it wouldn't--as a whitespace removal algorithm should 
be able to take into account line breaks as well.  But even if doesn't 
account for linebreaks, you should still see a reduction in the number 
of TLM instances created, as the FOText instances white-space remove 
themselves into extinction.  It's just that the reduction would not be 
as large as desired.

But then, proper TR14 line breaking needs
a precious character LB property and a whitespace status
too, so this can be combined. 


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.  But I believe this is 
minor to your point below.

The processing would be
roughly as follow:

*for* word *in* text (separated by whitespace)
   normalize the whitespace (optimize normalization away
for some whitespace status).


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 (depending on the whitespace removal property) as to whether or 
not to even remove whitespace to begin with.  It would be appear ideal 
to keep this business logic out of the Layout Manager classes--instead 
just send it whitespace-normalized (or not normalized, depending on the 
removal property) text, and have TLM process either equivalently.

Another issue, maybe just hairsplitting in this case, is that if it is a 
"word" that you're extracting in your for-loop,  you can't subsequently 
normalize the whitespace around it, because, by definition, you've just 
taken a "word".  To generalize what you're saying, I think you mean, 
"each word with assorted whitespace around it"--but that may be tough to 
precisely define within a for-loop. 


   calculate TR14 breaks at the beginning of the word
   *for* TR14 break possiblities *in* word
 *if* line full
check hyphenations
return previous break possiblity
   *end for*
 *end for*
This seems to make sense.  (Although this TR is rather sleep-inducing 
for me, at least--we may need to have someone else implement it! ;)

Glen

Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly

[J.Pietschmann]

Glen Mazza wrote:
A further optimization might be to do all this before
the Block is even parsed into FOText and Inline
objects, as many spaces-only objects would end up not
even needing to be created.
This will not account for spaces to be removed around line
breaks.
My preferred solution is to combine space processing with
break calculation. This needs some sort of status passed
through to the layout managers, perhaps as part of the
layout context. But then, proper TR14 line breaking needs
a precious character LB property and a whitespace status
too, so this can be combined. The processing would be
roughly as follow:
 *for* word *in* text (separated by whitespace)
   normalize the whitespace (optimize normalization away
for some whitespace status).
   calculate TR14 breaks at the beginning of the word
   *for* TR14 break possiblities *in* word
 *if* line full
check hyphenations
return previous break possiblity
   *end for*
 *end for*
Regards
J.Pietschmann

Re: Applying patches

[J.Pietschmann]

I'd still recommend installing cygwin (http://www.cygwin.com/).
The fileutils and patchutils packages contain many important
utilities, including dos2unix and unix2dos for batch line ending
conversion.
Be sure you install with "using DOS line endings". IIRC this
way most tools can use both LF and CRLF line endings (but always
create CRLF line endings).
J.Pietschmann

Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors

[J.Pietschmann]

Chris Bowditch wrote:
Just want to add that I realise changing TextLM.addAreas isnt the only 
other change required to get jusitification working. The Renderers will 
need changing too, but I'm against the renderers computing their own 
splits, just give them each word as its own area if justification is on.
This caused some problems in the maintenance branch code, although
the mistakes made there can be avoided.
The biggest problem is that lots of WordArea objects are created
which hang around some time and which also inherit a *lot* of
unnecessary (for them) fields from Area. I think some refactoring
of the Area hierarchy could be in order. The current state in the
maintenance branch is roughly like this:
  Box (not many attributes)
   + Space
   |   + DisplaySpace
   |   + InlineSpace (well, shoud be here, but actuall isn't)
   + Area (position, border, padding, children, heigth, width etc.)
   + BlockArea (content heigth&width etc.)
   |+ LineArea
   |+ etc.
   |
   + InlineArea
+ WordArea (ugh, maybe this was TextArea instead)
| + etc.
+ some non-word inline areas
Many inline areas can't have border, padding, background and
perhaps some other traits, and all the space is wasted in objects
which are instantiated *very often*. This added up to significant
ressource problems.
I'm still not quite sure what's the best approach to fix this.
In C++, it certainly would be multiple inheritance. In Java,
we could try using interfaces and some delegation:
 interface Area
 interface BlockArea extends Area
 interface InlineArea extends Area
 interface BorderPaddingBackgroundArea extends Area
 interface NonBorderPaddingBackgroundArea extends Area
 interface Space extends Area
 class AbstractArea implements Area
 class AbstractBlockArea implements BlockArea extends AbstractArea
 class AbstractInlineArea implements InlineArea extends AbstractArea
 class LineArea implements NonBorderPaddingBackgroundArea
   extends AbstractBlockArea
 class WordArea implements NonBorderPaddingBackgroundArea
   extends AbstractInlineArea
 class PageNumberReferenceArea extends WordArea
 ... and so on ...
(Well, because AbstractBlockArea is supposedly abstract, what class
represents ordinary block areas? We need a good name here :-) Note
that the real block area class may have traits which are not
applicable to for example the line area class or the table row area
class.)
The code for accessing the border, padding and background traits will
be duplicated in all classes implementing the BPBA interface, but given
that the traits are combined in a single class, this shouln't be much
of a problem, should it?
Some inline areas may not have children, this could lead another set
of interfaces.
A potentially second problem are the space non-areas. In the maintenance
branch code, display (block) space and inline space just have a height
(bpd) or a width (ipd), respectively. I'm not sure whether this is
sufficient, but perhaps it is.
Regards
J.Pietschmann

DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-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:

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).

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?

Thanks,
Glen

DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-17 08:21 ---
Created an attachment (id=11267)
another logging solution