you are right the trunk version is fine. I am still using the 0.20 version but I will soon upgrade
Eckard
| Jeremias Maerki <[EMAIL PROTECTED]>
07.03.2006 10:17
|
|
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
> [email protected]
>
>
> An
> [email protected]
> 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)
>
> <snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
