You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@enseeiht.fr> on 2005/06/12 17:20:07 UTC
Foray's font subsystem for Fop
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 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 welcome any additional thoughts/comments. Now starting to work...
Regards,
Vincent
Re: Foray's font subsystem for Fop
Posted by Glen Mazza <gr...@verizon.net>.
Welcome back Vincent! No, we switched from Avalon Logging to Commons
Logging some time ago. The FOPAvalonization page is rather out-of-date.
Victor and I tend to have different architectural ideas. I have not
researched his font work but I believe other team members are more
knowledgable about it. Fonts are hardly my speciality--I suspect our
font implementation in 1.0 can use some improvement though.
Thanks,
Glen
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 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 welcome any additional thoughts/comments. Now starting to work...
>
> Regards,
> Vincent
>
Re: Foray's font subsystem for Fop
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 14.06.2005 23:21:51 J.Pietschmann wrote:
> Vincent Hennebert wrote:
> > I was starting to
> > wonder what I could have done wrong so that things turn out that way.
>
> Just ignore the bickering for now. There seems to be a law that every
> Open Source project (or any other reasonably open project for that
> matter) sooner or later will get people with incompatible personalities,
> resulting in some mud slinging on mailing lists or worse. Notice the
> dismissal of one of the core BSD core developers last year, regular
> flame wars on the Linux Ethernet driver lists including heavy name
> calling and mutual allegations of incompetence, the fork of
> Geronimo off JBoss with associated ugliness and so on.
Not to mention the expulsion of an ASF committer from the Avalon project.
And later the violent shutdown of that project.
> No need for you to worry.
>
> J.Pietschmann
Jeremias Maerki
Re: Foray's font subsystem for Fop
Posted by "Peter B. West" <li...@pbw.id.au>.
J.Pietschmann wrote:
> Vincent Hennebert wrote:
>
>> I was starting to wonder what I could have done wrong so that things
>> turn out that way.
>
>
> Just ignore the bickering for now. There seems to be a law that every
> Open Source project (or any other reasonably open project for that
> matter) sooner or later will get people with incompatible personalities,
> resulting in some mud slinging on mailing lists or worse. Notice the
> dismissal of one of the core BSD core developers last year, regular
> flame wars on the Linux Ethernet driver lists including heavy name
> calling and mutual allegations of incompetence, the fork of
> Geronimo off JBoss with associated ugliness and so on.
>
> No need for you to worry.
Let's not forget Linus v. President Tridgell, a dispute with somewhat
wider impact.
It's almost as bad as proprietary projects, but everything is on public
view, everyone gets to express an opinion, and the individuals have real
alternatives on how to proceed after disagreements.
Peter
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
<http://folio.bkbits.net/> <- the atTridged version
Re: Foray's font subsystem for Fop
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Vincent Hennebert wrote:
> I was starting to
> wonder what I could have done wrong so that things turn out that way.
Just ignore the bickering for now. There seems to be a law that every
Open Source project (or any other reasonably open project for that
matter) sooner or later will get people with incompatible personalities,
resulting in some mud slinging on mailing lists or worse. Notice the
dismissal of one of the core BSD core developers last year, regular
flame wars on the Linux Ethernet driver lists including heavy name
calling and mutual allegations of incompetence, the fork of
Geronimo off JBoss with associated ugliness and so on.
No need for you to worry.
J.Pietschmann
Re: Foray's font subsystem for Fop
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Hello Jeremias,
I must convey that your answer was a relief for me ;-) I was starting to wonder
what I could have done wrong so that things turn out that way.
I keep your technical comments in mind for later, if I eventually may work on
this. Don't worry about the time I've already spent on: it was necessary for me
to feel capable of working on it. And while doing that I have discovered things
that can be useful for other tasks.
I'm just discovering the political side of open-source development. I guess it
can't be avoided but I just hope that it will not prevent Fop from becoming the
world's best FO processor. I think this goal is not that far away from some
others' [1]. Can't we try to calm down personal conflicts and put the stress on
technical quality?
I'm providing fresh blood. I'm not aware of past conflicts. Perhaps I can act as
a bridge between two different points of vue...
I'm still proposing to work on FOrayFont. In a technical point of vue it would
IMO be best to share a common code repository between the two projects. If it
appears not to be possible Victor will surely accept making a donation, and then
Fop can always develop its own improvements and adaptations on this basis.
However, I wouldn't like this eventuality, towards Victor.
Now perhaps that making a 1.0 release is a priority, at which case I can wait
before doing the work. In the meanwhile I can find other things to work on.
Perhaps it would be an additional benefit for a 1.0 release to have an improved
font subsystem, though.
Team, I'm now letting you make your decision. I'm keeping being connected.
Regards,
Vincent
[1] http://marc.theaimsgroup.com/?l=fop-dev&m=111755654014313&w=2
Re: Foray's font subsystem for Fop
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 14.06.2005 23:27:44 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Relying on static
> > variables in the case of logging is not necessarily bad.
>
> *cough* This depends on whether a single logger for all threads
> is not necessarily bad. I personally would probably prefer the
> possibility to direct logging for different threads into different
> destinations.
Me too, if you read everything I wrote. And you can strike the "probably"
for me. That statement was pretty general. That's why I talked about an
application-specific interface for special logging and notification
purposes. You could place the instance in a thread-local. Probably not
all logging needs to be per processing run. But some applications will
want specific and ideally parseable info back.
Jeremias Maerki
Re: Foray's font subsystem for Fop
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Relying on static
> variables in the case of logging is not necessarily bad.
*cough* This depends on whether a single logger for all threads
is not necessarily bad. I personally would probably prefer the
possibility to direct logging for different threads into different
destinations.
Some times ago Sun asked for ideas for language features for
the next major Java version, and closures were brought up on
jakarta general. I couldn't think of a use case in a language
with compile time variable binding, but now I think I should
reconsider...
J.Pietschmann
Re: Foray's font subsystem for Fop
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 14.06.2005 17:29:01 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > 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/commo
> > ns/logging/impl/AvalonLogger.html
>
> Thanks for the explanation. I went to a lot of trouble in FOray, mostly
> based on past conversations with you, to remove all such static-ish things,
> and I probably won't do anything that would require a client application to
> use anything like that. But maybe there are some other things that can be
> done.
I've seen that work and I'm sure it was worth it. Relying on static
variables in the case of logging is not necessarily bad. I know I
advocated the use of Avalon Logger at that time. I still think it is
good. The big advantage is really to be able to provide a new logger
instance for each processing run so you can log each document separately
which you can't if you use JCL's static logging pattern. But I've
learned from several people as well as from my own experience that
especially in the case of FOP the Avalon Logging approach can be
annoying and that per-processing-run loggin should be done through a
different mechanism, such as specialized, application-specific
interfaces. I haven't been able to get to the latter, yet. It's one of
my long term goals to provide better feedback to the caller about layout
problems or progress, as well as cleaner exception throwing.
> Foray addresses the logging problem through its tree organization
> (everything is a tree), and storing the Logger instance at the top of the
> tree, each child node being able to get the Logger instance from its parent.
The question here, of course, is if it is performant. It's probably ver
little but still, in a deep tree a logging call causes a number of
method calls to determine the logger instance.
> The only times it needs to get passed as a parameter is when moving from one
> module to another. So, for example if PDFDocument is at the top of the tree
> in the FOrayPDF module, it probably requires a Logger in its constructor,
The pure Avalon spirit would be to have that class implement LogEnabled.
> but then makes it available to all of its children. In some cases (like
> FOrayFont) it must be provided through an interface to keep the module as
> independent as it needs.
>
> During our previous Inversion of Control discussion, I briefly toyed with
> the idea of having the FontConsumer provide a method *to do its own
> logging*. So, rather than FontConsumer providing a Logger to FontServer
> (which you did not like), it would instead provide something like:
The whole discussion there was problematic because I didn't really have
time to explain everything to you. But again, I think it was worth it
from what I can see.
> public void logMessage(String message, int messageLevel) ;
>
> where messageLevel would indicate whether the message was debug, error,
> warning, etc. The things I dislike about this are 1) it is YALP (yet another
> logging protocol), which is what I understood Avalon to be trying to unify,
> and 2) it requires the client side to write code that seems pretty
> redundant. However, it is a pretty generic solution.
>
> One alternative would be for FontServer and FontConsumer to both allow
> Commons loggers as well as Avalon loggers, and for it to deal with the
> wrapping, etc. If it will help and if there are no better ideas, I am
> willing to do this.
I'd leave it as-is for the moment. As I said earlier, I believe it's
very easy to wrap a JCL logger into an Avalon Logger and pass that into
FontServer and FontConsumer. I'd even say you're on the safer side than
FOP because with the static logging you can't separate the logging
output for each processing run anymore. This is still something I found
important back when I was still coding heavy-duty FO processing servers.
And I know that many people have asked on the mailing list about
providing their own loggers to access the output made by FOP. That is
something that won't be possible ATM in CVS HEAD in a multi-threaded
environment. To get the log output per processing run you need to
serialize them.
Jeremias Maerki
Re: Foray's font subsystem for Fop
Posted by The Web Maestro <th...@gmail.com>.
On Jun 24, 2005, at 7:33 AM, Vincent Hennebert wrote:
> Hi all...
>
> Sorry to insist, but what is your final decision? A quick summary of
> the thread gives:
> - Jeremias +1
> - Simon +1
> - Glen +0
- Chris +1 (attached below)
> The FOray+aXSL stuff would be used in the form of a jar file put in
> the lib directory; FOray's avalon loggers would be wrapped into a JCL
> adapter for now.
>
> So?
> Vincent
It would've been better to forward the original VOTE message (attached
at the bottom for completeness), otherwise it's a little bit stickier,
since these 'votes' are scattered amongst two threads... (which is why
I replied to the original thread...)
Anyway... +1 from me!
Regards, Web Maestro Clay
Begin forwarded message:
> From: Chris Bowditch <bo...@hotmail.com>
> Date: June 24, 2005 7:58:35 AM PDT
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: FOrayFont?
> Reply-To: fop-dev@xmlgraphics.apache.org
> Reply-To: bowditch_chris@hotmail.com
>
> Vincent Hennebert wrote:
>
>> Hi all...
>> Sorry to insist, but what is your final decision? A quick summary of
>> the
>
> Thank you for insisting. I think it would be a great advantage if FOP
> used the Font module developed in FORay. So heres my +1
>
>> thread gives:
>> - Jeremias +1
>> - Simon +1
>> - Glen +0
>> The FOray+aXSL stuff would be used in the form of a jar file put in
>> the lib directory; FOray's avalon loggers would be wrapped into a JCL
>> adapter for now.
>
> I'm happy with that.
>
> Chris
On Jun 17, 2005, at 12:53 PM, Simon Pepping wrote:
> On Tue, Jun 14, 2005 at 10:33:10AM +0200, Jeremias Maerki wrote:
>>> 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.
>
> I am catching up on my email, and reading this thread several days
> after the fact. I did not see a reaction to Jeremias' above request.
>
> In general I am all for sharing an implementation of a piece of
> functionality that can be accessed via an agreed interface. Font
> services are really a good candidate. I have not studied FOray-Font,
> but I follow Jeremias' judgement on this that it is better than what
> we have now. Therefore I am in favour of using FOray-Font for
> satisfying FOP's font requirements.
>
> As long as FOray-Font is released under the Apache license, I believe
> that FOP should not have a problem with it, even if FOP would not have
> any control over it, as long as the implementation satisfies us. As
> soon as it does not, the license allows us to take a snapshot of the
> sources and go our own way. That is how I understand open source and
> the Apache license. I do not quite understand why we would need a
> grant. But even if so, Victor is willing to give one.
>
> That is my stand point. If this were a vote, my vote would be +1.
>
> Regards, Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.nl
>
>
Regards,
Web Maestro Clay
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: Foray's font subsystem for Fop
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Tue, Jun 14, 2005 at 10:33:10AM +0200, Jeremias Maerki wrote:
> > 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.
I am catching up on my email, and reading this thread several days
after the fact. I did not see a reaction to Jeremias' above request.
In general I am all for sharing an implementation of a piece of
functionality that can be accessed via an agreed interface. Font
services are really a good candidate. I have not studied FOray-Font,
but I follow Jeremias' judgement on this that it is better than what
we have now. Therefore I am in favour of using FOray-Font for
satisfying FOP's font requirements.
As long as FOray-Font is released under the Apache license, I believe
that FOP should not have a problem with it, even if FOP would not have
any control over it, as long as the implementation satisfies us. As
soon as it does not, the license allows us to take a snapshot of the
sources and go our own way. That is how I understand open source and
the Apache license. I do not quite understand why we would need a
grant. But even if so, Victor is willing to give one.
That is my stand point. If this were a vote, my vote would be +1.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
RE: Foray's font subsystem for Fop
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> 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/commo
> ns/logging/impl/AvalonLogger.html
Thanks for the explanation. I went to a lot of trouble in FOray, mostly
based on past conversations with you, to remove all such static-ish things,
and I probably won't do anything that would require a client application to
use anything like that. But maybe there are some other things that can be
done.
Foray addresses the logging problem through its tree organization
(everything is a tree), and storing the Logger instance at the top of the
tree, each child node being able to get the Logger instance from its parent.
The only times it needs to get passed as a parameter is when moving from one
module to another. So, for example if PDFDocument is at the top of the tree
in the FOrayPDF module, it probably requires a Logger in its constructor,
but then makes it available to all of its children. In some cases (like
FOrayFont) it must be provided through an interface to keep the module as
independent as it needs.
During our previous Inversion of Control discussion, I briefly toyed with
the idea of having the FontConsumer provide a method *to do its own
logging*. So, rather than FontConsumer providing a Logger to FontServer
(which you did not like), it would instead provide something like:
public void logMessage(String message, int messageLevel) ;
where messageLevel would indicate whether the message was debug, error,
warning, etc. The things I dislike about this are 1) it is YALP (yet another
logging protocol), which is what I understood Avalon to be trying to unify,
and 2) it requires the client side to write code that seems pretty
redundant. However, it is a pretty generic solution.
One alternative would be for FontServer and FontConsumer to both allow
Commons loggers as well as Avalon loggers, and for it to deal with the
wrapping, etc. If it will help and if there are no better ideas, I am
willing to do this.
Victor Mote
Re: Foray's font subsystem for Fop
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
RE: Foray's font subsystem for Fop
Posted by Victor Mote <vi...@outfitr.com>.
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