date:20040909

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FOTreeBuilder.java

2004-09-09 Thread Finn Bock

[Glen]
I think fox: should also be validated.  It's, by
definition, part of FOP core, and can't be
added/adjusted to by anyone but us.
Yes. I agree.
regards,
finn

Re: foray integration

2004-09-09 Thread Jeremias Maerki

Hi Victor.

On 08.09.2004 23:34:24 Victor Mote wrote:
 Jeremias Maerki wrote:
snip/
  What I hope is that you will continue to inform us of any 
  important developments on your side, that you also continue 
 
 I don't mind doing this if there are no objections to it. I have no wish to
 intrude or distract.

I don't think this is a problem. On the other side it may even be a good
thing to be able to exchange experiences and discuss issues (other than
design question I guess) that matter to all FO implementations. I hope
that, where easily possible, duplication of effort is avoided.

  to keep an eye on the upcoming XML Graphics project (when 
  it's finally looked at by the Board).
 
 To be honest, I must have missed some of the key parts of the conversation
 surrounding that project, and I don't really understand what is its purpose,
 except that it seems to be an attempt to factor out some code that is common
 to both FOP and Batik. If FOray's work is helpful along those lines, I'm
 glad for it, and I'll help in any reasonable way that I can.

The factoring out of common code and components is just part of my ideas
for the new project. It seems that there's a certain level of support
for that. The main goal of the XML Graphics PMC, however, is to split up
the Apache XML project to comply with the board's request to improve
oversight and legal protection for projects at the ASF.

  I'll try to monitor what goes on in your project. Let's just 
  not drift apart to far that we can't converge again if, one 
  day, we see a possibility to join forces again.
 
 FOP and FOray seem to have radically different and incompatible principles,
 so convergence will probably depend on one or both of us changing
 principles. Out of the 18 months I worked on FOP, the most productive half
 of it was entirely wasted, and I have no intention of making that mistake
 again. I've gotten 10 times as much productive work done in the last four
 months as I did in my entire time working on FOP, and I'm having 100 times
 as much fun. It's a little hard to imagine what might induce me to give that
 up. Nevertheless, I'll watch with you to see if that possibility presents
 itself.

I see that and I can only repeat myself: I realize that there are
radically different opinions on how the design for an FO layout engine
should look like but that there are no such disputes in the
infrastructure components. That's where I see possibilities to work
together without running into lengthy and unproductive discussions
because of different viewpoints. But let me take care of the transition
to the XML Graphics project first, and then we'll see if we can figure
out how we can work together on certain items.


Jeremias Maerki

[proposal] How to do logging from the command line (was: Re: Logging of exception.)

2004-09-09 Thread Jeremias Maerki

Hi Finn,

I took a look at it and I must say that I'm a bit confused, too.

Anyway, I have a proposal to make. I would expect a command-line
application to work like any other C-program such as grep, svn, ls or
whatever. That means you don't get any [INFO] before each line, but
you can define the log level (normally quiet, normal and verbose)
through command line switches. That'll work for most CLI-users.

Since the Fop class is the one to control the whole application it (or
rather the CommandLineOptions class) can also set up C-L to behave
exactly as explained above. That would probably mean not to use
SimpleLog but to provide a special implementation for command-line use.
At any rate, I don't agree with the way that SimpleLog is implemented.
Informational messages should go to System.out, errors to System.err.
Logging prefixes should be disabled. I've had to do the same for Avalon
Logging in Barcode4J [1] and I'm very pleased with the result. Using
this I was able to implement the Barcode4J CLI in a way that the
generated barcode could be output to System.out which may also be
desirable for certain people. You could even modify the whole thing in
way that you could implement FOP as a filter application getting the
input through System.in and sending the output to System.out, giving
error messages through System.err.

For those who know about C-L and want to do some special logging we
could have a command line switch that disables our special logger setup.
They can fully control C-L from outside.

For the cases where FOP is used embedded in a bigger software, FOP
shouldn't manipulate anything in C-L, it's simply the developer's job to
set up C-L from outside.

WDYT?

PS: One issue I found is that there are still several System.out/err
everywhere in the source code. These lines should be rewritten to use
C-L.

[1]
http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/org/krysalis/barcode4j/cli/AdvancedConsoleLogger.java?rev=1.2view=auto

On 08.09.2004 23:15:50 Finn Bock wrote:
Hi,

I didn't follow the discussion in the spring about command line -d and
commons-logging so I'm likely missing some important pieces, but I'm a
bit confused about the result.

If I attempt to render a fatally corrupt input fo file like:

fo:block/

, I get the expected SAXParseException message on the console and the
Turn on debugging for more information line.

When I turn on debugging, then the full exception is printed directly on
the console (without using C-L!) and no information about the exception
is sendt to C-L.

So the C-L debug level directly controls output to System.err. That
makes very little sense to me.

At the very least the exception should be logged to C-L, right?

I would also guess that any additional System.err output should be
controlled separately from C-L, with a -d option.

regards,
finn

Jeremias Maerki

28 matches

Mail list logo