Re: Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.

2006-03-07 Thread Jeremias Maerki
If the TTFReader is supposed to be used as an embedded component, it's
best to separate the logic from the command-line interface. System.out
calls would then not be permitted in the logic, only in the command-line
interface. I don't like when things are mixed. I've just had a look at
the code and as far as I can see, all log calls go to the logger, so it
would actually be only a matter of setting up the logging right in your
case. You may not even have to change anything. I did not remember that
the whole thing was so well cleaned-up already.

On 07.03.2006 10:06:31 Eckard_Buchner wrote:
> i could do something like this: Add a parameter -v (verbose) and doing 
> system.out only when this parameter is set. Additionally there would be a 
> boolean property, because when I embed the reader I do not use the main() 
> method. Do you agree?
> 
> Eckard
> 
> 
> 
> 
> Jeremias Maerki <[EMAIL PROTECTED]> 
> 07.03.2006 08:45
> Bitte antworten an
> fop-users@xmlgraphics.apache.org
> 
> 
> An
> fop-users@xmlgraphics.apache.org
> Kopie
> 
> Thema
> Re: Antwort: Re: Changing logging behavior in an embedded application.
> 
> 
> 
> 
> 
> 
> You're welcome to improve TTFReader in FOP Trunk if it doesn't do
> exactly what you want it to do. TTFReader was never designed to be used
> as anything else than a command-line tool which is called once for each
> font. If people have additional needs we're gladly accepting patches
> against FOP Trunk.
> 
> On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > > FOP does have a few System.out.println calls in its source code but
> > > these are only in places where those are ok, i.e. in command-line
> > > handling code
> > 
> > IMHO this is not the case with the TTFReader. It tells you about each 
> file 
> > it reads and writes. If you convert a couple of files at once this is a 
> > little inconvenient. Maybe it should have a silent mode? BTW if you 
> embed 
> > the TTF Reader i would prefer getting exceptions when something goes 
> wrong 
> > rather than geting null return (and a stack trace in stdout)
> 
> 


Jeremias Maerki


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



Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.

2006-03-07 Thread Eckard_Buchner

i could do something like this: Add
a parameter -v (verbose) and doing system.out only when this parameter
is set. Additionally there would be a boolean property, because when I
embed the reader I do not use the main() method. Do you agree?

Eckard






Jeremias Maerki <[EMAIL PROTECTED]>

07.03.2006 08:45



Bitte antworten an
fop-users@xmlgraphics.apache.org





An
fop-users@xmlgraphics.apache.org


Kopie



Thema
Re: Antwort: Re: Changing logging behavior
in an embedded application.








You're welcome to improve TTFReader in FOP Trunk if
it doesn't do
exactly what you want it to do. TTFReader was never designed to be used
as anything else than a command-line tool which is called once for each
font. If people have additional needs we're gladly accepting patches
against FOP Trunk.

On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > FOP does have a few System.out.println calls in its source code
but
> > these are only in places where those are ok, i.e. in command-line
> > handling code
> 
> IMHO this is not the case with the TTFReader. It tells you about each
file 
> it reads and writes. If you convert a couple of files at once this
is a 
> little inconvenient. Maybe it should have a silent mode? BTW if you
embed 
> the TTF Reader i would prefer getting exceptions when something goes
wrong 
> rather than geting null return (and a stack trace in stdout)




Jeremias Maerki


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