Vincent Hennebert wrote:

> 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:

First, thanks for your interest, and welcome to FOP. Even though I am not an
active FOP developer anymore, I'm glad to see it making progress. And I
agree that integrating FOrayFont with FOP should be quite feasible.

> - 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?

To be honest, I don't know what the benefits of one over the other are. I
was just feeling pretty good about getting all of the System.out stuff
consolidated into a logger. If it makes sense to convert to commons logging,
I'll be glad to do that. I assume it probably does or FOP wouldn't have gone
down that path. I've just never spent any time on the topic. Can an Avalon
logger be encapsulated in a Commons logger? If so, then it would be a very
easy decision to go with Commons.

I'll answer the question about how many and where to create the loggers
below.

> - 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 am not familiar enough with FOP's current state to advise which class
should the FontConsumer, but I can describe it for you and one of the other
FOP developers can probably give you a good specific answer based on the
description. When I first split the font code off a year ago, I used the
FontInfo class for the FontConsumer implementation, and eventually renamed
it FOrayDocument. That was based on the maintenance branch code, but I think
there was at one time a class with the same name and purpose in the trunk
also. At any rate, the class should be one which represents the input
document. The purpose of the FontConsumer interface is to give the
FontServer a way to keep different documents separate, so that fonts can be
properly subsetted and encoded. As long as you pick a class that has exactly
one instance for document A and exactly one instance for document B, and
those two instances are different, it really doesn't matter much.

WRT the loggers, one is required to create a FontServer. FontServer uses
this for messages that are not directly related to a FontConsumer, e.g. as
it is initializing, etc. Each FontConsumer is required to provide a logger
as well, and FontServer uses that logger for messages that are specific to
that FontConsumer. Of course, it doesn't care if they are the same one.

Jeremias has commented before that he doesn't like FontConsumer passing a
Logger to FontServer. I couldn't figure out how to implement the alternative
that he suggested (Avalon Inversion of Control), and I think I last asked
him to write a patch illustrating the change when he gets a chance. I would
be glad to discuss the matter again, but you need to know that on that point
at least, we may have some work to do.

In FOray we actually store the FontServer instance in the FOraySession
instance, which is at the very top of our tree. Since one FontServer can
serve multiple documents, there was no need for us to provide means for more
than one FontServer. This may enter in to your decision about which class to
use as FontConsumer as well. The FontConsumer implementation needs to be
able to provide the FontServer instance, so it should either store it
internally or be able to get it from where it is stored. This was done to
prevent FontServer from being static. Whenever a FOP class needs a font
service, it just needs to know how to find the appropriate FontConsumer
instance -- it can get to all font services there.

VERY IMPORTANT -- FOrayFont is actually an implementation of axslFont.
axslFont is an interface, and FOrayFont is one (probably the only)
implementation of that interface. There is nothing wrong with integrating
directly to Foray, but it seems much better to integrate to the interface
instead. That gives FOP maximum flexibility if someone develops a better
implementation at some point. The amount of conversion work will be the same
either way.

I will be very happy to assist you in any way possible, short of writing FOP
code.

Victor Mote

Reply via email to