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
