xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Foray's font subsystem for Fop
Date Tue, 14 Jun 2005 08:33:10 GMT
Vincent,

thank you very much for wanting to help. You've seen that you
inadvertently touched a sensitive subject. I'm really sad that these
things must happen. Let me just comment on your initial mail from a
purely technical perspective.

On 12.06.2005 17:20:07 Vincent Hennebert wrote:
> Hi Fop Team and Victor,
> 
> I'm considering to adapt Foray's font subsystem to Fop. I have already 
> experimented a bit and the thing seems to be rather feasible. So far I have 
> encountered two problems:
> 
> - logging mechanism: Foray uses the avalon framework while Fop uses commons 
> logging. The 2 APIs are similar but I suppose I'll have to convert the avalon 
> stuff into commons. Or are there any plans to change the logging mechanism (I'm 
> thinking about the FOPAvalonization Wiki page)? Another minor problem will be to 
> plug the right logger to the font subsystem. I guess only one logger is created 
> and passed through all classes?

The logging problem is a minor one. There's a wrapper for JCL that
easily wraps an Avalon Logger [1]. But that's obviously the exact
opposite of what you need. On the other side, creating an implementation
of Avalon's Logger interface that wraps a JCL logger should be just as
easy. Unfortunately, such a class doesn't exist, yet, but that's written
within 10 minutes.

Let me explain why we switched from Avalon Logging to JCL. Avalon
Loggers are always passed from container to child object (Inversion of
Control). A class using a JCL logger always fetches a logger from a
factory. So the difference is in acquiring a logger but there's also
another aspect: With Avalon Logger you can use different loggers on
different instances of the same class which you can't if you use the
normal JCL pattern of using a static variable for holding the logger.
The static variable has certain advantages, too: You don't need a
variable on every object instance and you don't have to pass Loggers all
around in the system, which is particularly problematic or at least
cumbersome in FOP. JCL makes many thing easier.

But as I hinted above there's no problem connecting the two approaches.
Both are light-weight and therefore easy to handle.

[1] http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/AvalonLogger.html

> - the font subsystem is based on a client/server architecture; the question is: 
> which Fop class should be made a FontConsumer? And where should the FontServer 
> be created and held? So far I've used FOEventHandler as a FontConsumer and a 
> holder of a FontServer. It's quite convenient but I'm not sure at all that it is 
> good design; I'm not yet used to Fop's overall architecture.

I think it would have to be a separate class and held by either
FOEventHandler or FOUserAgent. But we've already stretched the
FOUserAgent a bit already. Anyway, I don't think this is such an
important decision. This can always be improved.

> I welcome any additional thoughts/comments. Now starting to work...

I wish you had asked before diving into this. Before FOray-Font can be
integrated with FOP we need to have a vote on this among the committers
and frankly, I'm sure such a thing will cost a lot of energy. I'm not
going to push in that direction without any hint of support from at
least two other committers around here. I hope we will get more opinions.


Jeremias Maerki


Mime
View raw message