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 Victor Mote <vi...@outfitr.com> on 2005/09/03 07:23:42 UTC
Logging for FOrayFont
I just completed a project to make FOray's logging a bit more flexible. It
now logs from an interface called org.axsl.common.PseudoLogger. Logging
levels are the same as those for java.util.logging.Level (in Java 1.4 and
higher), except that integrals are used instead of Level instances.
I also wrote an implementation org.axsl.common.AvalonLogger, which FOray
uses (for now) when it needs to *create* a logger. Since all loggers in the
font system are supplied to the font system (instead of created within it),
FOP should simply pass a different implementation to keep its logging
consistent within itself. The AvalonLogger is a thin wrapper around an, er,
Avalon ConsoleLogger, and is essentially an Adapter between the Avalon
logging system and PseudoLogger. A similar approach can be used with
whatever logging system FOP decides it wants to use. Writing the adapter
should be fairly trivial, and it should be possible to use any logging
system with this approach.
I hope this makes the integration work a bit easier and the results more
satisfactory to FOP. Please let me know if you have questions.
Victor Mote
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Hi Joerg:
> Victor Mote wrote:
> > OK. Still I miss your point.
>
> Well, I think loggin is much overrated and it is really
> overdone in FOP.
I agree. Some of that is a function of being alpha-quality code. As people
get more comfortable that something actually does work, you are right that a
lot of the logging can be removed. The communal nature of open source and
the transient nature of the pool of people working on various pieces of code
contributes to the problem as well. If you have to wade through a lot of
logging code to get anything done, you are more likely to yank it out than
if you ... never actually look at it again.
As far as users go, some folks like a lot of logging, others like less or
none. High-volume batch users generally want more, interactive users want
less. Not every interesting thing that happens warrants throwing an
exception. I have been working on font-selection today, and some users might
be interested to know or even record on a permanent basis that their
first-choice of font-family was not used.
> Fatal errors are fatal errors. Just throw an exception and
> let someone else figure out what to do. Some examples from
> the FOP code where logging doesn't help:
...
I agree.
> FOP needs a facility to notify a user about warnings,
> recoverable errors and progress reports. There may be a
> separate facility to provide debug for developers and yet
> another to provide out-of-band results like ressource ussage
> statistics and number of generated pages.
> I don't think that generously sprinkling log.stuff()
> statements all over the place is the best solution to the
> problems above, even though this seems to fit.
I generally agree, although I seem to like logging better than you or
Jeremias. This could be a cultural legacy from my one-compile-per-day,
the-lineprinter-is-your-debugger days. And perhaps I'll be more in agreement
after I understand the alternatives better.
Anyway, thanks for making your point more clear.
Victor Mote
Re: Logging for FOrayFont
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> OK. Still I miss your point.
Well, I think loggin is much overrated and it is really overdone
in FOP.
Fatal errors are fatal errors. Just throw an exception and let
someone else figure out what to do. Some examples from the FOP
code where logging doesn't help:
public int getValue() {
log.error("getValue() called on " + enumProperty + " length");
return 0;
}
if ((bfSet & MAXSET) != 0) {
// Warning: min>max, resetting max to min
log.error("forcing max to min in LengthRange");
}
maximum = minimum;
public Source resolve(String href, String base)
throws javax.xml.transform.TransformerException {
....
try {
// the above failed, we give it another go in case
// the href contains only a path then file: is assumed
absoluteURL = new URL("file:" + href);
} catch (MalformedURLException mfue) {
log.error("Error with URL '" + href + "': " +
mue.getMessage(), mue);
return null;
}
Especially the latter gets a "Duh!", because of:
public Source resolveURI(String uri) {
...
if (uriResolver != null) {
try {
source = uriResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error("Attempt to resolve URI '" + uri + "' failed: ", te);
}
}
if (source == null) {
// URI Resolver not configured or returned null, use default
// resolver
try {
source = foURIResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error("Attempt to resolve URI '" + uri + "' failed: ", te);
}
}
FOP needs a facility to notify a user about warnings, recoverable
errors and progress reports. There may be a separate facility to
provide debug for developers and yet another to provide out-of-band
results like ressource ussage statistics and number of generated pages.
I don't think that generously sprinkling log.stuff() statements all
over the place is the best solution to the problems above, even though
this seems to fit.
J.Pietschmann
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> If you've looked into a fair number of open source projects,
> and add projects from your work environment, you'll probably
> see certain abstractions over and over again.
> Counting the number of reincarnations, logging certainly
> comes into the top ten, I guess even at position three after
> configuration services and i18n. The tendency to have a
> project specific abstraction, however small, isn't new, check
> out the history part in the syslogd docs.
>
> If you are interested in a list of other recurring themes
> beside the three named above:
> - service discovery, often including loading code or data
> from a directory or some other repository
> - URL resolving
> - URI, URL, pathname and search path handling as Strings
> - command line argument parsing, maybe as part or complement
> of a configuration service
> - object pooling, in particular network connection pooling
> and multiplexing
> - XML creation
> - Java object persistence
> The list isn't complete of course.
OK. Still I miss your point. It could be any one of the following:
1. You are arguing against the "no external dependencies" idea.
2. You support the "no external dependencies" idea, and find it humorous
when someone has to reinvent the wheel to comply with it.
3. You support the "no external dependencies" idea, and think that there was
some more elegant solution that FOray should have implemented.
4. You agree with Jeremias that there is no need for logging information to
pass through an interface between two subsystems.
5. You agree that logging for such a system is not necessary.
The list isn't complete of course.
Victor Mote
Re: Logging for FOrayFont
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Your meaning here is, at best, ambiguous. Please clarify.
If you've looked into a fair number of open source projects,
and add projects from your work environment, you'll probably
see certain abstractions over and over again.
Counting the number of reincarnations, logging certainly comes
into the top ten, I guess even at position three after
configuration services and i18n. The tendency to have a
project specific abstraction, however small, isn't new,
check out the history part in the syslogd docs.
If you are interested in a list of other recurring themes
beside the three named above:
- service discovery, often including loading code or data
from a directory or some other repository
- URL resolving
- URI, URL, pathname and search path handling as Strings
- command line argument parsing, maybe as part or complement
of a configuration service
- object pooling, in particular network connection pooling
and multiplexing
- XML creation
- Java object persistence
The list isn't complete of course.
J.Pietschmann
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> > /me ducks.
>
> Hehe. I've also thought again that designing certain
> interfaces (and piling them on each other) must be really really fun.
Your meaning here is, at best, ambiguous. Please clarify.
Victor Mote
Re: Logging for FOrayFont
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> I'm ever growing more cofident that
> developer-oriented logging should be done through a static logging
> facility (like Commons Logging) and that end-user-oriented logging needs
> to operate per processing run (like Avalon Logger) but not necessarily
> through a standard logging abstraction interface, but rather an
> application-specific one that provides exactly what the application
> needs to send feedback to the end-users.
That's a major part of the points at the end of
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200508.mbox/%3c431626FB.4090702@yahoo.de%3e
The idea is that FOP sends certain events (or messages) to the User
Agent interface and let the app specific user agent implementation sort
out whether it wants to log it, throw an exception, show a message box,
whatever.
The static debug/trace mechanism is a welcomed refinement, I'd
thought of exposing the logger from the user agent to the rest
of the code for this purpose. It is quite possible that the event
signalling methods proposed in the post above need to be split
up further.
> /me ducks.
Hehe. I've also thought again that designing certain interfaces
(and piling them on each other) must be really really fun.
J.Pietschmann
Re: Logging for FOrayFont
Posted by Jeremias Maerki <de...@greenmail.ch>.
I'm sorry but I've got to stop here. No energy left for this discussion.
I didn't manage to get my meaning across and so we're talking about
different things. I'll try to look into aXSL and FOray later and see if
I can create a patch to demonstrate what I was talking about. Sorry for
wasting your time. This was really not directed at you but rather at the
FOP team so they know we have a potential problem when moving code over
to Commons. It wasn't supposed to extend into such a discussion. I'm
anxious to see what happens when I actually start to migrate code to
Commons....
On 05.09.2005 22:29:46 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > > A PseudoLogger is required (but can be passed
> > > null) in the FontServer constructor
> >
> > That's an implementation detail and not a problem. It has
> > nothing to do with the API. FontServer is an interface in the
> > API and you are talking about the implementation of
> > FontServer here, I assume.
>
> Well, it may have nothing to do with the aXSL API, but it certainly has
> something to do with the FOray API. To implement FOray (which I understand
> to be the discussion), you have to do both. If it is wrong to demand a
> logging mechanism in aXSL's API, how can it then be right to do so in
> FOray's API? It sounds like I could solve all of your concerns by creating a
> FOray FontConsumer implementation that is an abstract class, making you pick
> some class to extend it, and then simply demanding a logging mechanism in
> the implementation's constructor.
>
> Am I right? If so, doesn't it all seem silly? The client application now has
> to have implementation-specific code embedded at FontConsumer (document)
> construction. Poof. Pluggability just disappeared. For what benefit? None.
> Your client application still supplies exactly the same thing it supplied
> the other way.
>
> Really, why does FOP care whether it needs to supply logging information
> because aXSL requires it or because FOray requires it?
>
> > > and is required in a method in
> > > FontConsumer. But FontConsumer is implemented on the client
> > side, in
> > > which the client application tells FOray about itself.
> >
> > This method getPseudoLogger() is what caught my purist's eye
> > in the first place. It breaks IoC.
>
> I don't care. (I am sure that comes across more rudely than I intend). There
> are more important things here.
>
> > > Second, why should FOray limit its clients to only use
> > static logging?
> > > If the client has to expose a static logging mechanism to FOray in
> > > order to get static logging to work, what can possibly be
> > wrong with
> > > exposing a non-static logging mechanism to FOray? Right now, FOray
> > > doesn't care whether static or non-static logging is used.
> > Why should it?
> >
> > Exactly. Why should it? If you remove all logging concerns
> > from the work interface you don't do any assumptions about
> > how logging is done. The presence of getPseudoLogger(),
> > though, produces a strong emphasis on non-static logging.
>
> Not true. Your PseudoLogger implementation can use whatever logging it wants
> to, or, as may please you better, send it to /dev/null.
>
> Again, if you accept implementation constructors as part of the API that FOP
> must deal with, then I think your whole line of reasoning disappears here.
>
> > > Third, lets define the "concern". <important>My understanding of
> > > Separation of Concerns in this case is that FOrayFont owns
> > the concern
> > > that a message needs to be logged, and that the client application
> > > owns the concern of how that logging should be
> > > accomplished.</important>
> > >
> > > In order to maintain that Separation of Concerns, one of two things
> > > must
> > > happen:
> > > 1. The client must tell the component how stuff should be logged.
> > > 2. The server must tell the client what should be logged.
> > >
> > > This means some logging-related stuff will appear in the interface
> > > between the two.
> >
> > Not IMO. It can be an implementation detail. See more below.
> >
> > > The design considerations are as follows:
> > > 1. FOrayFont needs to be able to log messages.
> >
> > For whom? For the developer or for the end-user? Because
>
> Ah, now this is what I consider to be an implementation detail!
>
> > that's what I've learned during the past months: That it
> > should be well divided between the two audiences. The
> > speciality is that the developer doesn't need a logger per
> > processing run (i.e. non-static logging) and the end-user
> > often needs more than just pure Strings through a generic
> > logging interface. Note that this is not yet reality in FOP
> > but I believe it will be soon.
>
> Well, I noticed that you chose to ignore the <important> tag, and it shows
> up here. Why should the component concern itself with the differences
> between the two audiences? If a user wants to log debug or trace messages
> into a permanent file somewhere, what business is that of FOrayFont's????
> All it should do is respond to the level of detail that is requested by the
> client application, and to place it where the client application wants, both
> of which, AFAICT, you won't allow me to find out.
>
> > > 2. FOrayFont needs to be able to work with any client system,
> > > regardless of their preferences on logging.
> >
> > Nobody challenges that. Due to input from Batik the question
> > is raised whether such a library should do any logging at
> > all. Don't get me wrong.
>
> If you don't want to do any logging, send the log messages to /dev/null. But
> it is not reasonable to insist that other client applications must
> effectively do the same thing by never getting the opportunity to log.
>
> > I'm all for developer-oriented logging, even in basic
> > libraries. It's just that I somehow need to find out how to
> > accomodate everyone, like you intend, too. The complication
> > here is that I needed to bring a new consideration into play.
> > And we really need to pay attention what we are talking
> > about: the aXSL API or the FOray implementation. If you read
> > my message again I specifically talk about aXSL, not FOray.
>
> OK. Again, I must ask for a proposal for a solution. Submit patches for aXSL
> and FOray that allow FOray to log messages on a document-by-document basis
> and retain pluggability, and we can talk about this again.
>
> > > I can keep all logging internal to the FOrayFont subsystem, which
> > > would mean that the client application (FOP) has no control
> > over the
> > > logging whatsoever. Very bad. FOray has to guess what kind
> > of logger
> > > to use, and it will never be right.
> >
> > It's not true that it doesn't have control. It's just that
> > (static) logging is controlled from elsewhere.
> >
> > > I can expose a logging interface that allows the client
> > application to
> > > handle logging its own way. This has been the approach used so far.
> > >
> > > The only other solution is a bit more complex, and IMO, quickly
> > > becomes ugly. FOrayFont currently asks some client object
> > to implement
> > > the FontConsumer interface. Instead of having FontConsumer
> > provide a
> > > PseudoLogger, it could have a method instead that logs messages:
> > >
> > > /**
> > > * @param level An integer describing the level at which this
> > > message should be logged,
> > > * that is, error, warning, debug, etc.
> > > */
> > > public void logMessage(String message, int level) ;
> >
> > That would be worse, IMO.
>
> I agree.
>
> > > Further, does a logMessage() method still expose logging
> > functionality
> > > in a way that is objectionable to you and to Batik?
> >
> > Yes. IMO the API should not expose any aspect of logging,
> > only pure work functionality. An implementation of the API,
> > on the other side, will then expose any technical means
> > (methods, config files...) to configure/control logging. Do
> > you find logging aspects in APIs like DOM, JAXP, JDBC, EJB
> > etc.? No, I don't think so. But any DOM implementation, or
> > JDBC driver or Enterprise Java Bean is allowed to do logging
> > of some sort and there are ways/approaches to configure it.
> > Or take my JAXG. It doesn't care about how and if
> > (developer-oriented) logging is done. Only the
> > implementations define ways to control that if they support
> > it. That is the key point!
>
> OK. Point taken. The difference is that FontConsumer is pretty passive. An
> implementation will never instantiate a FontConsumer implementation. The
> *client* application implements it. I think of this as a feature not a flaw,
> else I would change it.
>
> > > > Now, I know this has the potential to spark a heated debate again
> > > > and it raises question marks about the FOrayFont integration, but
> > > > ATM I really don't know what to do about it right now. I just
> > > > realized we have a problem here. I/we made promises on
> > > > general@xmlgraphics.apache.org to try to remove logging and other
> > > > external dependencies (like Avalon) for the common components
> > > > because that's something which is very important to the
> > Batik side.
> > >
> > > So, then, how are those components supposed to log anything? Or, if
> > > they are to log using their own static stuff, how can this be
> > > configured by the client?
> >
> > Eventually such basic libraries shouldn't log anything
> > anymore. That's the big dilemma I'm sitting in, the one I
> > need to find a way out of.
>
> Arggh. So, we disagree here. Is it so terrible to simply implement
> PseudoLogger to ignore any input it gets?
>
> > Anyway, ways to remove the necessity to log are: unit tests
> > and stabilization. The problem is getting rid of something so
> > extremely handy but actually completely unnecessary for
> > something basic like a PDF or font library. But I'd never
> > want to get rid of the ability to log in a complex system
> > like a layout engine.
>
> Hmmm. I had forgotten that PDF and font libraries were non-complex. :-)
>
> Also, I wouldn't spend very much time trying to reconcile "extremely handy"
> with "completely unnecessary". That one will keep you busy for awhile.
> Better IMO would be to pick one and try to live with it. Or, better yet, to
> *allow* both by picking the lowest common denominator, which in this case is
> "extremely handy". If Batik thinks font subsystem is "completely
> unnecessary" and FOP thinks it is "extremely handy", then Batis should send
> logging output to /dev/null and FOP should do something more interesting
> with it. Both can be made happy this way.
>
> > > > Maybe we could have two different implementations of the
> > > > PDFTextElementBridge so Batik can do native text rendering in a
> > > > different way than FOP but there's still the PDF library that
> > > > depends largely on the font subsystem. But maybe this could be
> > > > handled in a similar way. I need to investigate that a
> > little more.
> > >
> > > I'll be glad to help any way I can, and at this stage FOray
> > can be flexible.
> > > But I must admit that I don't follow the logic. I need for
> > someone to
> > > do one of the following:
> > > 1. explain which of the two design considerations listed above you
> > > would have your components abandon
> >
> > From my POV as a developer in general: none of them.
> > From my POV as the one who pushes for XML Graphics Commons: both.
> >
> > See my problem?
>
> Yes, you want A and not A at the same time. I am frankly unwilling to let
> you delegate that problem to me :-) at least until I hear a better reason
> than has been given so far.
>
> > > 2. suggest a solution that allows *both* design
> > considerations to be
> > > retained, but does not have the client either doing the logging or
> > > telling the component how to do the logging.
> >
> > Let logging be entirely an implementation detail, not a part
> > of the functional API.
>
> Again, the implementation you have chosen needs it anyway. So, the effective
> API that FOP is using is functionally the same either way.
>
> > > I still find myself learning new tricks,
> >
> > Me too! Me tooooo!
> >
> > > so perhaps there is some other
> > > elegant alternative that I am simply too blind to yet see.
> >
> > We don't need a solution right now. I would just like you to
> > think about removing logging as an aspect of the aXSL APIs.
> > That would make things easier. But it's also just an aspect
> > of my general view of API design.
>
> OK. I have thought about it. I don't see a way to do it without giving
> something up that is more important.
>
> > It actually doesn't have so much to do with Batik and XML
> > Graphics Commons.
> >
> > I just needed to raise the overall concern about external
> > dependencies because of what Thomas said in our discussion
> > about XML Graphics Commons and because of the stuff we voted
> > on. We don't have to find a solution today. I don't even have
> > time for that right now. I can't continue with moving the
> > main components to Commons right now anyway because I need to
> > wait for what Vincent is doing. Furthermore, I want to get
> > that first preview release out of the door and that can't
> > happen with XML Graphics Commons. It's too late for that.
>
> I think a reasonable approach would be to let Vincent implement it as it
> stands, and see whether anybody complains. If so, I think it is entirely
> reasonable to insist that they offer an alternative to consider.
>
> > > The deeper question here is whether it is really wise to avoid all
> > > external dependencies. FOray is invested heavily in the idea that
> > > reusability is A Good Thing. My sense is that FOP still
> > struggles with this question.
> >
> > I usually don't use external dependencies without considering
> > all the consequences. I'm all for reuse. The problem is that
>
> Using external dependencies judiciously is wise. Refusing to use them at all
> seems very unwise IMO. You will get to rewrite Ant, Xalan, and Xerces for
> starters.
>
> > we found out that Batik and FOP have an extremely differing
> > views on these things and we decided to start sharing (PDF
> > lib etc.) and transferring (Transcoders) components inside
> > the XML Graphics project. This has some consequences.
> > As I said, I just wanted everyone to know that there are
> > issues that will need to be dealt with someday but we don't
> > have to do it right now.
> > If there's an obvious solution, good, but I don't see it right now.
>
> OK. I don't either. I am trying to be responsive to your concerns, but admit
> that I don't yet understand or appreciate them properly. I am ... still
> trying to understand why this is important.
>
> Victor Mote
Jeremias Maerki
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Simon Pepping wrote:
> It would of course be easier if all components would use a
> standard interface like Commons Logging. But that is not
> going to happen in this world.
FWIW, I am not opposed to having FOray use Commons Logging instead of a
home-grown interface. But that is actually an external dependency as well,
so that was not an option. And from the standpoint of a component developer,
you have to ask yourself how often you can afford to switch from Avalon to
Commons to ...
It would (maybe) help some if java itself would endorse an interface for
this purpose.
Victor Mote
Re: Logging for FOrayFont
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Mon, Sep 05, 2005 at 09:35:26PM +0200, Jeremias Maerki wrote:
> As I said, widely differing views between Batik and FOP about this. In
> my own personal opinion, I'm with you. From the POV of XML Graphics
> Commons we have a problem. We've voted on the plan for Commons where we
> said that we'd try to remove the dependency on Commons Logging. If there
> is a problem with that, the right place to raise this is
> general@xmlgraphics.apache.org.
That means that those Commons components will have to define their own
interface to which they are willing to send logging events, just like
ForayFont does. FOP will have to implement all interfaces defined by
the libraries it uses. It should do so on top of a Commons Logger
instance, to preserve Commons Logging user configurability.
It would of course be easier if all components would use a standard
interface like Commons Logging. But that is not going to happen in
this world.
My remark about runtime information to debug a system configuration is
inspired by a TeX system, which needs to load many component files. I
realized that it uses a different method. Its resolver library does
indeed no logging. Instead, there is a stand-alone front end to it
that the user must run separately to obtain configuration debugging
information. For example, when in my LaTeX run class X is not loaded
as I expect, I use this app (kpsewhich) to find out where the resolver
library thinks the class X is. It also displays search path
information, and information about how the search path is constructed
from the configuration file and the built in path components.
Regards, Simon
> On 05.09.2005 21:15:50 Simon Pepping wrote:
> <snip/>
> > I am not sure that I understand everything that is being said
> > here. But I am alarmed when I hear that basic libraries, in this case
> > the FontServer, shouldn't log anymore. In my experience a font system
> > requires powerful logging, in order to expose runtime behaviour to the
> > systems manager or end user. Configuring font systems and
> > understanding why a piece of font software does not use it as you
> > expect, is a hard task that requires suitable runtime information from
> > the software.
>
> Jeremias Maerki
>
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Logging for FOrayFont
Posted by Jeremias Maerki <de...@greenmail.ch>.
As I said, widely differing views between Batik and FOP about this. In
my own personal opinion, I'm with you. From the POV of XML Graphics
Commons we have a problem. We've voted on the plan for Commons where we
said that we'd try to remove the dependency on Commons Logging. If there
is a problem with that, the right place to raise this is
general@xmlgraphics.apache.org.
On 05.09.2005 21:15:50 Simon Pepping wrote:
<snip/>
> I am not sure that I understand everything that is being said
> here. But I am alarmed when I hear that basic libraries, in this case
> the FontServer, shouldn't log anymore. In my experience a font system
> requires powerful logging, in order to expose runtime behaviour to the
> systems manager or end user. Configuring font systems and
> understanding why a piece of font software does not use it as you
> expect, is a hard task that requires suitable runtime information from
> the software.
Jeremias Maerki
Re: Logging for FOrayFont
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Mon, Sep 05, 2005 at 07:33:33PM +0200, Jeremias Maerki wrote:
>
> On 05.09.2005 17:05:48 Victor Mote wrote:
> > Jeremias Maerki wrote:
> >
> > The design considerations are as follows:
> > 1. FOrayFont needs to be able to log messages.
>
> For whom? For the developer or for the end-user? Because that's what
> I've learned during the past months: That it should be well divided
> between the two audiences. The speciality is that the developer doesn't
> need a logger per processing run (i.e. non-static logging) and the
> end-user often needs more than just pure Strings through a generic
> logging interface. Note that this is not yet reality in FOP but I
> believe it will be soon.
>
> > > Now, I know this has the potential to spark a heated debate
> > > again and it raises question marks about the FOrayFont
> > > integration, but ATM I really don't know what to do about it
> > > right now. I just realized we have a problem here. I/we made
> > > promises on general@xmlgraphics.apache.org to try to remove
> > > logging and other external dependencies (like Avalon) for the
> > > common components because that's something which is very
> > > important to the Batik side.
> >
> > So, then, how are those components supposed to log anything? Or, if they are
> > to log using their own static stuff, how can this be configured by the
> > client?
>
> Eventually such basic libraries shouldn't log anything anymore. That's
> the big dilemma I'm sitting in, the one I need to find a way out of.
> Anyway, ways to remove the necessity to log are: unit tests and
> stabilization. The problem is getting rid of something so extremely
> handy but actually completely unnecessary for something basic like a PDF
> or font library. But I'd never want to get rid of the ability to log in
> a complex system like a layout engine.
I am not sure that I understand everything that is being said
here. But I am alarmed when I hear that basic libraries, in this case
the FontServer, shouldn't log anymore. In my experience a font system
requires powerful logging, in order to expose runtime behaviour to the
systems manager or end user. Configuring font systems and
understanding why a piece of font software does not use it as you
expect, is a hard task that requires suitable runtime information from
the software.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> > A PseudoLogger is required (but can be passed
> > null) in the FontServer constructor
>
> That's an implementation detail and not a problem. It has
> nothing to do with the API. FontServer is an interface in the
> API and you are talking about the implementation of
> FontServer here, I assume.
Well, it may have nothing to do with the aXSL API, but it certainly has
something to do with the FOray API. To implement FOray (which I understand
to be the discussion), you have to do both. If it is wrong to demand a
logging mechanism in aXSL's API, how can it then be right to do so in
FOray's API? It sounds like I could solve all of your concerns by creating a
FOray FontConsumer implementation that is an abstract class, making you pick
some class to extend it, and then simply demanding a logging mechanism in
the implementation's constructor.
Am I right? If so, doesn't it all seem silly? The client application now has
to have implementation-specific code embedded at FontConsumer (document)
construction. Poof. Pluggability just disappeared. For what benefit? None.
Your client application still supplies exactly the same thing it supplied
the other way.
Really, why does FOP care whether it needs to supply logging information
because aXSL requires it or because FOray requires it?
> > and is required in a method in
> > FontConsumer. But FontConsumer is implemented on the client
> side, in
> > which the client application tells FOray about itself.
>
> This method getPseudoLogger() is what caught my purist's eye
> in the first place. It breaks IoC.
I don't care. (I am sure that comes across more rudely than I intend). There
are more important things here.
> > Second, why should FOray limit its clients to only use
> static logging?
> > If the client has to expose a static logging mechanism to FOray in
> > order to get static logging to work, what can possibly be
> wrong with
> > exposing a non-static logging mechanism to FOray? Right now, FOray
> > doesn't care whether static or non-static logging is used.
> Why should it?
>
> Exactly. Why should it? If you remove all logging concerns
> from the work interface you don't do any assumptions about
> how logging is done. The presence of getPseudoLogger(),
> though, produces a strong emphasis on non-static logging.
Not true. Your PseudoLogger implementation can use whatever logging it wants
to, or, as may please you better, send it to /dev/null.
Again, if you accept implementation constructors as part of the API that FOP
must deal with, then I think your whole line of reasoning disappears here.
> > Third, lets define the "concern". <important>My understanding of
> > Separation of Concerns in this case is that FOrayFont owns
> the concern
> > that a message needs to be logged, and that the client application
> > owns the concern of how that logging should be
> > accomplished.</important>
> >
> > In order to maintain that Separation of Concerns, one of two things
> > must
> > happen:
> > 1. The client must tell the component how stuff should be logged.
> > 2. The server must tell the client what should be logged.
> >
> > This means some logging-related stuff will appear in the interface
> > between the two.
>
> Not IMO. It can be an implementation detail. See more below.
>
> > The design considerations are as follows:
> > 1. FOrayFont needs to be able to log messages.
>
> For whom? For the developer or for the end-user? Because
Ah, now this is what I consider to be an implementation detail!
> that's what I've learned during the past months: That it
> should be well divided between the two audiences. The
> speciality is that the developer doesn't need a logger per
> processing run (i.e. non-static logging) and the end-user
> often needs more than just pure Strings through a generic
> logging interface. Note that this is not yet reality in FOP
> but I believe it will be soon.
Well, I noticed that you chose to ignore the <important> tag, and it shows
up here. Why should the component concern itself with the differences
between the two audiences? If a user wants to log debug or trace messages
into a permanent file somewhere, what business is that of FOrayFont's????
All it should do is respond to the level of detail that is requested by the
client application, and to place it where the client application wants, both
of which, AFAICT, you won't allow me to find out.
> > 2. FOrayFont needs to be able to work with any client system,
> > regardless of their preferences on logging.
>
> Nobody challenges that. Due to input from Batik the question
> is raised whether such a library should do any logging at
> all. Don't get me wrong.
If you don't want to do any logging, send the log messages to /dev/null. But
it is not reasonable to insist that other client applications must
effectively do the same thing by never getting the opportunity to log.
> I'm all for developer-oriented logging, even in basic
> libraries. It's just that I somehow need to find out how to
> accomodate everyone, like you intend, too. The complication
> here is that I needed to bring a new consideration into play.
> And we really need to pay attention what we are talking
> about: the aXSL API or the FOray implementation. If you read
> my message again I specifically talk about aXSL, not FOray.
OK. Again, I must ask for a proposal for a solution. Submit patches for aXSL
and FOray that allow FOray to log messages on a document-by-document basis
and retain pluggability, and we can talk about this again.
> > I can keep all logging internal to the FOrayFont subsystem, which
> > would mean that the client application (FOP) has no control
> over the
> > logging whatsoever. Very bad. FOray has to guess what kind
> of logger
> > to use, and it will never be right.
>
> It's not true that it doesn't have control. It's just that
> (static) logging is controlled from elsewhere.
>
> > I can expose a logging interface that allows the client
> application to
> > handle logging its own way. This has been the approach used so far.
> >
> > The only other solution is a bit more complex, and IMO, quickly
> > becomes ugly. FOrayFont currently asks some client object
> to implement
> > the FontConsumer interface. Instead of having FontConsumer
> provide a
> > PseudoLogger, it could have a method instead that logs messages:
> >
> > /**
> > * @param level An integer describing the level at which this
> > message should be logged,
> > * that is, error, warning, debug, etc.
> > */
> > public void logMessage(String message, int level) ;
>
> That would be worse, IMO.
I agree.
> > Further, does a logMessage() method still expose logging
> functionality
> > in a way that is objectionable to you and to Batik?
>
> Yes. IMO the API should not expose any aspect of logging,
> only pure work functionality. An implementation of the API,
> on the other side, will then expose any technical means
> (methods, config files...) to configure/control logging. Do
> you find logging aspects in APIs like DOM, JAXP, JDBC, EJB
> etc.? No, I don't think so. But any DOM implementation, or
> JDBC driver or Enterprise Java Bean is allowed to do logging
> of some sort and there are ways/approaches to configure it.
> Or take my JAXG. It doesn't care about how and if
> (developer-oriented) logging is done. Only the
> implementations define ways to control that if they support
> it. That is the key point!
OK. Point taken. The difference is that FontConsumer is pretty passive. An
implementation will never instantiate a FontConsumer implementation. The
*client* application implements it. I think of this as a feature not a flaw,
else I would change it.
> > > Now, I know this has the potential to spark a heated debate again
> > > and it raises question marks about the FOrayFont integration, but
> > > ATM I really don't know what to do about it right now. I just
> > > realized we have a problem here. I/we made promises on
> > > general@xmlgraphics.apache.org to try to remove logging and other
> > > external dependencies (like Avalon) for the common components
> > > because that's something which is very important to the
> Batik side.
> >
> > So, then, how are those components supposed to log anything? Or, if
> > they are to log using their own static stuff, how can this be
> > configured by the client?
>
> Eventually such basic libraries shouldn't log anything
> anymore. That's the big dilemma I'm sitting in, the one I
> need to find a way out of.
Arggh. So, we disagree here. Is it so terrible to simply implement
PseudoLogger to ignore any input it gets?
> Anyway, ways to remove the necessity to log are: unit tests
> and stabilization. The problem is getting rid of something so
> extremely handy but actually completely unnecessary for
> something basic like a PDF or font library. But I'd never
> want to get rid of the ability to log in a complex system
> like a layout engine.
Hmmm. I had forgotten that PDF and font libraries were non-complex. :-)
Also, I wouldn't spend very much time trying to reconcile "extremely handy"
with "completely unnecessary". That one will keep you busy for awhile.
Better IMO would be to pick one and try to live with it. Or, better yet, to
*allow* both by picking the lowest common denominator, which in this case is
"extremely handy". If Batik thinks font subsystem is "completely
unnecessary" and FOP thinks it is "extremely handy", then Batis should send
logging output to /dev/null and FOP should do something more interesting
with it. Both can be made happy this way.
> > > Maybe we could have two different implementations of the
> > > PDFTextElementBridge so Batik can do native text rendering in a
> > > different way than FOP but there's still the PDF library that
> > > depends largely on the font subsystem. But maybe this could be
> > > handled in a similar way. I need to investigate that a
> little more.
> >
> > I'll be glad to help any way I can, and at this stage FOray
> can be flexible.
> > But I must admit that I don't follow the logic. I need for
> someone to
> > do one of the following:
> > 1. explain which of the two design considerations listed above you
> > would have your components abandon
>
> From my POV as a developer in general: none of them.
> From my POV as the one who pushes for XML Graphics Commons: both.
>
> See my problem?
Yes, you want A and not A at the same time. I am frankly unwilling to let
you delegate that problem to me :-) at least until I hear a better reason
than has been given so far.
> > 2. suggest a solution that allows *both* design
> considerations to be
> > retained, but does not have the client either doing the logging or
> > telling the component how to do the logging.
>
> Let logging be entirely an implementation detail, not a part
> of the functional API.
Again, the implementation you have chosen needs it anyway. So, the effective
API that FOP is using is functionally the same either way.
> > I still find myself learning new tricks,
>
> Me too! Me tooooo!
>
> > so perhaps there is some other
> > elegant alternative that I am simply too blind to yet see.
>
> We don't need a solution right now. I would just like you to
> think about removing logging as an aspect of the aXSL APIs.
> That would make things easier. But it's also just an aspect
> of my general view of API design.
OK. I have thought about it. I don't see a way to do it without giving
something up that is more important.
> It actually doesn't have so much to do with Batik and XML
> Graphics Commons.
>
> I just needed to raise the overall concern about external
> dependencies because of what Thomas said in our discussion
> about XML Graphics Commons and because of the stuff we voted
> on. We don't have to find a solution today. I don't even have
> time for that right now. I can't continue with moving the
> main components to Commons right now anyway because I need to
> wait for what Vincent is doing. Furthermore, I want to get
> that first preview release out of the door and that can't
> happen with XML Graphics Commons. It's too late for that.
I think a reasonable approach would be to let Vincent implement it as it
stands, and see whether anybody complains. If so, I think it is entirely
reasonable to insist that they offer an alternative to consider.
> > The deeper question here is whether it is really wise to avoid all
> > external dependencies. FOray is invested heavily in the idea that
> > reusability is A Good Thing. My sense is that FOP still
> struggles with this question.
>
> I usually don't use external dependencies without considering
> all the consequences. I'm all for reuse. The problem is that
Using external dependencies judiciously is wise. Refusing to use them at all
seems very unwise IMO. You will get to rewrite Ant, Xalan, and Xerces for
starters.
> we found out that Batik and FOP have an extremely differing
> views on these things and we decided to start sharing (PDF
> lib etc.) and transferring (Transcoders) components inside
> the XML Graphics project. This has some consequences.
> As I said, I just wanted everyone to know that there are
> issues that will need to be dealt with someday but we don't
> have to do it right now.
> If there's an obvious solution, good, but I don't see it right now.
OK. I don't either. I am trying to be responsive to your concerns, but admit
that I don't yet understand or appreciate them properly. I am ... still
trying to understand why this is important.
Victor Mote
Re: Logging for FOrayFont
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 05.09.2005 17:05:48 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > I got a little shock when I realized a problem I didn't think
> > of when we discussed moving FOP components over to XML
> > Graphics Commons. We said we would try to remove logging code
> > from these basic components entirely.
> >
> > Now, I forgot to consider the decision to use FOrayFont made earlier.
> > The external dependency on FOrayFont also would be a problem
> > in itself because the Batik side has strong feelings against
> > external dependencies.
> > We need to think about what to do about this WRT the PDF and
> > PS transcoders. Optimized text painting in these two
> > transcoders depends a lot on the font subsystem.
>
> Well, the little change I just made removes entirely any dependency on
> Avalon in any FOray code, except for the fact that Ant seems to need it for
> logging (needed for creating hyphenation patterns and such). There is no
> longer any Avalon code in FOrayFont. In fact, that was the primary
> motivation for making the change. The Avalon Logger interface would have
> been quite a sufficient solution for anything that FOray needs, and, since
> it is an interface, adapters could be written from it to anything else, just
> as Vincent and I have been discussing for the PseudoLogger interface.
Yeah, yet another generic logger abstraction interface. Sigh.
> > Aside from that, a thought about the aXSL APIs: Being an
> > ex-Avaloner SoC (separation of concerns) is a big concern to
> > me. The functional API of a package should IMO actually not
> > deal with (or rather expose) logging at all. It's a separate
> > concern. I'm ever growing more cofident that
> > developer-oriented logging should be done through a static
> > logging facility (like Commons Logging) and that
> > end-user-oriented logging needs to operate per processing run
> > (like Avalon Logger) but not necessarily through a standard
> > logging abstraction interface, but rather an
> > application-specific one that provides exactly what the
> > application needs to send feedback to the end-users. In that
> > light, a PDF or font library shouldn't expose any logging
> > facilities at all or at least to static logging that is
> > externally configured.
>
> First, do you understand that the FOrayFont library does not "expose any
> logging facilities" to the client, but instead asks the client to expose the
> logging facilities to it?
Yes. Sorry for the not quite accurate wording plus a typo. Let's try
again: [a work interface] shouldn't expose any logging specifica (as
they are a separate concern, see Avalon's LogEnabled interface or newer
dependency injection systems). If developer-oriented logging is
absolutely necessary I prefer static logging (like Commons Logging or
Log4J) today.
> A PseudoLogger is required (but can be passed
> null) in the FontServer constructor
That's an implementation detail and not a problem. It has nothing to do
with the API. FontServer is an interface in the API and you are talking
about the implementation of FontServer here, I assume.
> and is required in a method in
> FontConsumer. But FontConsumer is implemented on the client side, in which
> the client application tells FOray about itself.
This method getPseudoLogger() is what caught my purist's eye in the
first place. It breaks IoC.
> Second, why should FOray limit its clients to only use static logging? If
> the client has to expose a static logging mechanism to FOray in order to get
> static logging to work, what can possibly be wrong with exposing a
> non-static logging mechanism to FOray? Right now, FOray doesn't care whether
> static or non-static logging is used. Why should it?
Exactly. Why should it? If you remove all logging concerns from the work
interface you don't do any assumptions about how logging is done. The
presence of getPseudoLogger(), though, produces a strong emphasis on
non-static logging.
> Third, lets define the "concern". <important>My understanding of Separation
> of Concerns in this case is that FOrayFont owns the concern that a message
> needs to be logged, and that the client application owns the concern of how
> that logging should be accomplished.</important>
>
> In order to maintain that Separation of Concerns, one of two things must
> happen:
> 1. The client must tell the component how stuff should be logged.
> 2. The server must tell the client what should be logged.
>
> This means some logging-related stuff will appear in the interface between
> the two.
Not IMO. It can be an implementation detail. See more below.
> The design considerations are as follows:
> 1. FOrayFont needs to be able to log messages.
For whom? For the developer or for the end-user? Because that's what
I've learned during the past months: That it should be well divided
between the two audiences. The speciality is that the developer doesn't
need a logger per processing run (i.e. non-static logging) and the
end-user often needs more than just pure Strings through a generic
logging interface. Note that this is not yet reality in FOP but I
believe it will be soon.
> 2. FOrayFont needs to be able to work with any client system, regardless of
> their preferences on logging.
Nobody challenges that. Due to input from Batik the question is raised
whether such a library should do any logging at all. Don't get me wrong.
I'm all for developer-oriented logging, even in basic libraries. It's
just that I somehow need to find out how to accomodate everyone, like
you intend, too. The complication here is that I needed to bring a new
consideration into play. And we really need to pay attention what we are
talking about: the aXSL API or the FOray implementation. If you read my
message again I specifically talk about aXSL, not FOray.
> I can keep all logging internal to the FOrayFont subsystem, which would mean
> that the client application (FOP) has no control over the logging
> whatsoever. Very bad. FOray has to guess what kind of logger to use, and it
> will never be right.
It's not true that it doesn't have control. It's just that (static) logging
is controlled from elsewhere.
> I can expose a logging interface that allows the client application to
> handle logging its own way. This has been the approach used so far.
>
> The only other solution is a bit more complex, and IMO, quickly becomes
> ugly. FOrayFont currently asks some client object to implement the
> FontConsumer interface. Instead of having FontConsumer provide a
> PseudoLogger, it could have a method instead that logs messages:
>
> /**
> * @param level An integer describing the level at which this message
> should be logged,
> * that is, error, warning, debug, etc.
> */
> public void logMessage(String message, int level) ;
That would be worse, IMO.
> The problem here is that I need to then create another interface that has
> something similar that can pass itself to FontServer so that general (not
> document-specific) logging messages can be handled. I also need to create
> one for Graphics, Text, FOTree, etc. I will have 10 or 12 methods in various
> interfaces that all do the same thing. This seems silly to me. This begs for
> a type to do this, which the Avalon Logger interface provided and which
> PseudoLogger provides as well.
>
> Further, does a logMessage() method still expose logging functionality in a
> way that is objectionable to you and to Batik?
Yes. IMO the API should not expose any aspect of logging, only pure work
functionality. An implementation of the API, on the other side, will
then expose any technical means (methods, config files...) to
configure/control logging. Do you find logging aspects in APIs like DOM,
JAXP, JDBC, EJB etc.? No, I don't think so. But any DOM implementation,
or JDBC driver or Enterprise Java Bean is allowed to do logging of some
sort and there are ways/approaches to configure it. Or take my JAXG. It
doesn't care about how and if (developer-oriented) logging is done. Only
the implementations define ways to control that if they support it. That
is the key point!
> > Now, I know this has the potential to spark a heated debate
> > again and it raises question marks about the FOrayFont
> > integration, but ATM I really don't know what to do about it
> > right now. I just realized we have a problem here. I/we made
> > promises on general@xmlgraphics.apache.org to try to remove
> > logging and other external dependencies (like Avalon) for the
> > common components because that's something which is very
> > important to the Batik side.
>
> So, then, how are those components supposed to log anything? Or, if they are
> to log using their own static stuff, how can this be configured by the
> client?
Eventually such basic libraries shouldn't log anything anymore. That's
the big dilemma I'm sitting in, the one I need to find a way out of.
Anyway, ways to remove the necessity to log are: unit tests and
stabilization. The problem is getting rid of something so extremely
handy but actually completely unnecessary for something basic like a PDF
or font library. But I'd never want to get rid of the ability to log in
a complex system like a layout engine.
> > Maybe we could have two different implementations of the
> > PDFTextElementBridge so Batik can do native text rendering in
> > a different way than FOP but there's still the PDF library
> > that depends largely on the font subsystem. But maybe this
> > could be handled in a similar way. I need to investigate that
> > a little more.
>
> I'll be glad to help any way I can, and at this stage FOray can be flexible.
> But I must admit that I don't follow the logic. I need for someone to do one
> of the following:
> 1. explain which of the two design considerations listed above you would
> have your components abandon
From my POV as a developer in general: none of them.
From my POV as the one who pushes for XML Graphics Commons: both.
See my problem?
> 2. suggest a solution that allows *both* design considerations to be
> retained, but does not have the client either doing the logging or telling
> the component how to do the logging.
Let logging be entirely an implementation detail, not a part of the
functional API.
> I still find myself learning new tricks,
Me too! Me tooooo!
> so perhaps there is some other
> elegant alternative that I am simply too blind to yet see.
We don't need a solution right now. I would just like you to think about
removing logging as an aspect of the aXSL APIs. That would make things
easier. But it's also just an aspect of my general view of API design.
It actually doesn't have so much to do with Batik and XML Graphics
Commons.
I just needed to raise the overall concern about external dependencies
because of what Thomas said in our discussion about XML Graphics Commons
and because of the stuff we voted on. We don't have to find a solution
today. I don't even have time for that right now. I can't continue with
moving the main components to Commons right now anyway because I need to
wait for what Vincent is doing. Furthermore, I want to get that first
preview release out of the door and that can't happen with XML Graphics
Commons. It's too late for that.
> The deeper question here is whether it is really wise to avoid all external
> dependencies. FOray is invested heavily in the idea that reusability is A
> Good Thing. My sense is that FOP still struggles with this question.
I usually don't use external dependencies without considering all the
consequences. I'm all for reuse. The problem is that we found out that Batik
and FOP have an extremely differing views on these things and we decided
to start sharing (PDF lib etc.) and transferring (Transcoders)
components inside the XML Graphics project. This has some consequences.
As I said, I just wanted everyone to know that there are issues that
will need to be dealt with someday but we don't have to do it right now.
If there's an obvious solution, good, but I don't see it right now.
Jeremias Maerki
Re: ForayFont dependency in graphics commons; was: Logging for FOrayFont
Posted by Jeremias Maerki <de...@greenmail.ch>.
Thanks for chiming in, Thomas.
It should be possible to have that pluggable for Batik. After all, the
text bridge mechanism from Batik provides an ideal way to plug that
functionality in.
A few random notes on the topic:
- The PDF library has dependencies on the font subsystem, so we would
need to make sure that Batik without special text handling in PDF will
work without the font subsystem classes present in the classpath.
- Maybe something could be done to embed the fonts of the Java2D origin
as Type 3 fonts. Keiron has left a TODO item about that somewhere.
Shouldn't be that hard to do.
- There IS benefit in painting text as text instead of shapes. You get a
lot of speed and a much smaller file size.
- I have the impression that the FOP-grown text bridges currently
don't work though I haven't investigated closely, yet.
I hope we'll find a good way to handle this. I'll start
copying/migrating components over to Commons as soon as the first FOP
preview release is out.
On 06.09.2005 14:31:38 Thomas DeWeese wrote:
> Hi all,
>
> So this is a tricky one. I really feel like I'm getting in the
> way of FOP stuff, but on the other hand as far as I can see the
> ForayFont stuff would have almost zero advantage for Batik's use
> of the PDF Transcoder.
>
> This is because Batik has to do all of it's own text layout and
> it currently does this using the Java2D Platform Fonts, TrueType
> (referenced from CSS), and of course SVG fonts. Right now there are
> a few 'trivial' text cases that are handled by the PDF Graphics2D
> 'drawString' stuff that might benefit but basically, as far as I
> can see, this would - for Batik - be another very low functionality
> external dependency.
>
> That said I know that currently one of the stumbling blocks for
> extracting the PDFGraphics2D from the rest of FOP is the the
> font subsystem. There is a bit of an inherent conflict between
> using Graphics2D as a 'high level transcoding' API and advanced
> font/text handling. Currently, the list of Java2D fonts (from
> GraphicsEnvironment is totally independent of the Graphics2D). Now
> of course the current state of text output for PDF is fairly abysmal
> from Batik (anything beyond very simple text is done as shapes), but
> fixing that would probably be a huge piece of work.
>
> I personally would lean towards leaving the font-subsystem
> as pluggable.
>
> BTW as far as the PsuedoLogger stuff is concerned this is fine
> with me (and is actually my preferred way to handle this). It doesn't
> force any logger on me, yet one can plug it into any existing logging
> system with a fairly trivial piece of code. Although this may not
> matter depending on how we approach Font support.
>
> > Jeremias Maerki wrote:
> >
> >> I got a little shock when I realized a problem I didn't think of when we
> >> discussed moving FOP components over to XML Graphics Commons. We said we
> >> would try to remove logging code from these basic components entirely.
> >> Now, I forgot to consider the decision to use FOrayFont made earlier.
> >> The external dependency on FOrayFont also would be a problem in itself
> >> because the Batik side has strong feelings against external dependencies.
> >> We need to think about what to do about this WRT the PDF and PS
> >> transcoders. Optimized text painting in these two transcoders depends a
> >> lot on the font subsystem.
>
> Chris Bowditch wrote:
> > Ouch! The FORayFont integration offers a hugh functional benefit over
> > the current Font code, so it would be a real shame to lose it. IIRC
> > Thomas was saying that he was against dependencies that don't yield any
> > functional benefit, i.e. logging and avalon framework. Since FORayFont
> > does have functional benefits for both projects perhaps it won't be such
> > a problem for Batik to include it. But I guess that is up the Batik team
> > to decide.
Jeremias Maerki
ForayFont dependency in graphics commons; was: Logging for FOrayFont
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi all,
So this is a tricky one. I really feel like I'm getting in the
way of FOP stuff, but on the other hand as far as I can see the
ForayFont stuff would have almost zero advantage for Batik's use
of the PDF Transcoder.
This is because Batik has to do all of it's own text layout and
it currently does this using the Java2D Platform Fonts, TrueType
(referenced from CSS), and of course SVG fonts. Right now there are
a few 'trivial' text cases that are handled by the PDF Graphics2D
'drawString' stuff that might benefit but basically, as far as I
can see, this would - for Batik - be another very low functionality
external dependency.
That said I know that currently one of the stumbling blocks for
extracting the PDFGraphics2D from the rest of FOP is the the
font subsystem. There is a bit of an inherent conflict between
using Graphics2D as a 'high level transcoding' API and advanced
font/text handling. Currently, the list of Java2D fonts (from
GraphicsEnvironment is totally independent of the Graphics2D). Now
of course the current state of text output for PDF is fairly abysmal
from Batik (anything beyond very simple text is done as shapes), but
fixing that would probably be a huge piece of work.
I personally would lean towards leaving the font-subsystem
as pluggable.
BTW as far as the PsuedoLogger stuff is concerned this is fine
with me (and is actually my preferred way to handle this). It doesn't
force any logger on me, yet one can plug it into any existing logging
system with a fairly trivial piece of code. Although this may not
matter depending on how we approach Font support.
> Jeremias Maerki wrote:
>
>> I got a little shock when I realized a problem I didn't think of when we
>> discussed moving FOP components over to XML Graphics Commons. We said we
>> would try to remove logging code from these basic components entirely.
>> Now, I forgot to consider the decision to use FOrayFont made earlier.
>> The external dependency on FOrayFont also would be a problem in itself
>> because the Batik side has strong feelings against external dependencies.
>> We need to think about what to do about this WRT the PDF and PS
>> transcoders. Optimized text painting in these two transcoders depends a
>> lot on the font subsystem.
Chris Bowditch wrote:
> Ouch! The FORayFont integration offers a hugh functional benefit over
> the current Font code, so it would be a real shame to lose it. IIRC
> Thomas was saying that he was against dependencies that don't yield any
> functional benefit, i.e. logging and avalon framework. Since FORayFont
> does have functional benefits for both projects perhaps it won't be such
> a problem for Batik to include it. But I guess that is up the Batik team
> to decide.
Re: Logging for FOrayFont
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> I got a little shock when I realized a problem I didn't think of when we
> discussed moving FOP components over to XML Graphics Commons. We said we
> would try to remove logging code from these basic components entirely.
> Now, I forgot to consider the decision to use FOrayFont made earlier.
> The external dependency on FOrayFont also would be a problem in itself
> because the Batik side has strong feelings against external dependencies.
> We need to think about what to do about this WRT the PDF and PS
> transcoders. Optimized text painting in these two transcoders depends a
> lot on the font subsystem.
Ouch! The FORayFont integration offers a hugh functional benefit over
the current Font code, so it would be a real shame to lose it. IIRC
Thomas was saying that he was against dependencies that don't yield any
functional benefit, i.e. logging and avalon framework. Since FORayFont
does have functional benefits for both projects perhaps it won't be such
a problem for Batik to include it. But I guess that is up the Batik team
to decide.
<snip/>
Chris
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> I got a little shock when I realized a problem I didn't think
> of when we discussed moving FOP components over to XML
> Graphics Commons. We said we would try to remove logging code
> from these basic components entirely.
>
> Now, I forgot to consider the decision to use FOrayFont made earlier.
> The external dependency on FOrayFont also would be a problem
> in itself because the Batik side has strong feelings against
> external dependencies.
> We need to think about what to do about this WRT the PDF and
> PS transcoders. Optimized text painting in these two
> transcoders depends a lot on the font subsystem.
Well, the little change I just made removes entirely any dependency on
Avalon in any FOray code, except for the fact that Ant seems to need it for
logging (needed for creating hyphenation patterns and such). There is no
longer any Avalon code in FOrayFont. In fact, that was the primary
motivation for making the change. The Avalon Logger interface would have
been quite a sufficient solution for anything that FOray needs, and, since
it is an interface, adapters could be written from it to anything else, just
as Vincent and I have been discussing for the PseudoLogger interface.
> Aside from that, a thought about the aXSL APIs: Being an
> ex-Avaloner SoC (separation of concerns) is a big concern to
> me. The functional API of a package should IMO actually not
> deal with (or rather expose) logging at all. It's a separate
> concern. I'm ever growing more cofident that
> developer-oriented logging should be done through a static
> logging facility (like Commons Logging) and that
> end-user-oriented logging needs to operate per processing run
> (like Avalon Logger) but not necessarily through a standard
> logging abstraction interface, but rather an
> application-specific one that provides exactly what the
> application needs to send feedback to the end-users. In that
> light, a PDF or font library shouldn't expose any logging
> facilities at all or at least to static logging that is
> externally configured.
First, do you understand that the FOrayFont library does not "expose any
logging facilities" to the client, but instead asks the client to expose the
logging facilities to it? A PseudoLogger is required (but can be passed
null) in the FontServer constructor and is required in a method in
FontConsumer. But FontConsumer is implemented on the client side, in which
the client application tells FOray about itself.
Second, why should FOray limit its clients to only use static logging? If
the client has to expose a static logging mechanism to FOray in order to get
static logging to work, what can possibly be wrong with exposing a
non-static logging mechanism to FOray? Right now, FOray doesn't care whether
static or non-static logging is used. Why should it?
Third, lets define the "concern". <important>My understanding of Separation
of Concerns in this case is that FOrayFont owns the concern that a message
needs to be logged, and that the client application owns the concern of how
that logging should be accomplished.</important>
In order to maintain that Separation of Concerns, one of two things must
happen:
1. The client must tell the component how stuff should be logged.
2. The server must tell the client what should be logged.
This means some logging-related stuff will appear in the interface between
the two.
The design considerations are as follows:
1. FOrayFont needs to be able to log messages.
2. FOrayFont needs to be able to work with any client system, regardless of
their preferences on logging.
I can keep all logging internal to the FOrayFont subsystem, which would mean
that the client application (FOP) has no control over the logging
whatsoever. Very bad. FOray has to guess what kind of logger to use, and it
will never be right.
I can expose a logging interface that allows the client application to
handle logging its own way. This has been the approach used so far.
The only other solution is a bit more complex, and IMO, quickly becomes
ugly. FOrayFont currently asks some client object to implement the
FontConsumer interface. Instead of having FontConsumer provide a
PseudoLogger, it could have a method instead that logs messages:
/**
* @param level An integer describing the level at which this message
should be logged,
* that is, error, warning, debug, etc.
*/
public void logMessage(String message, int level) ;
The problem here is that I need to then create another interface that has
something similar that can pass itself to FontServer so that general (not
document-specific) logging messages can be handled. I also need to create
one for Graphics, Text, FOTree, etc. I will have 10 or 12 methods in various
interfaces that all do the same thing. This seems silly to me. This begs for
a type to do this, which the Avalon Logger interface provided and which
PseudoLogger provides as well.
Further, does a logMessage() method still expose logging functionality in a
way that is objectionable to you and to Batik?
> Now, I know this has the potential to spark a heated debate
> again and it raises question marks about the FOrayFont
> integration, but ATM I really don't know what to do about it
> right now. I just realized we have a problem here. I/we made
> promises on general@xmlgraphics.apache.org to try to remove
> logging and other external dependencies (like Avalon) for the
> common components because that's something which is very
> important to the Batik side.
So, then, how are those components supposed to log anything? Or, if they are
to log using their own static stuff, how can this be configured by the
client?
> Maybe we could have two different implementations of the
> PDFTextElementBridge so Batik can do native text rendering in
> a different way than FOP but there's still the PDF library
> that depends largely on the font subsystem. But maybe this
> could be handled in a similar way. I need to investigate that
> a little more.
I'll be glad to help any way I can, and at this stage FOray can be flexible.
But I must admit that I don't follow the logic. I need for someone to do one
of the following:
1. explain which of the two design considerations listed above you would
have your components abandon
2. suggest a solution that allows *both* design considerations to be
retained, but does not have the client either doing the logging or telling
the component how to do the logging.
I still find myself learning new tricks, so perhaps there is some other
elegant alternative that I am simply too blind to yet see.
The deeper question here is whether it is really wise to avoid all external
dependencies. FOray is invested heavily in the idea that reusability is A
Good Thing. My sense is that FOP still struggles with this question.
Victor Mote
Re: Logging for FOrayFont
Posted by Jeremias Maerki <de...@greenmail.ch>.
I got a little shock when I realized a problem I didn't think of when we
discussed moving FOP components over to XML Graphics Commons. We said we
would try to remove logging code from these basic components entirely.
Now, I forgot to consider the decision to use FOrayFont made earlier.
The external dependency on FOrayFont also would be a problem in itself
because the Batik side has strong feelings against external dependencies.
We need to think about what to do about this WRT the PDF and PS
transcoders. Optimized text painting in these two transcoders depends a
lot on the font subsystem.
Aside from that, a thought about the aXSL APIs: Being an ex-Avaloner SoC
(separation of concerns) is a big concern to me. The functional API of a
package should IMO actually not deal with (or rather expose) logging at
all. It's a separate concern. I'm ever growing more cofident that
developer-oriented logging should be done through a static logging
facility (like Commons Logging) and that end-user-oriented logging needs
to operate per processing run (like Avalon Logger) but not necessarily
through a standard logging abstraction interface, but rather an
application-specific one that provides exactly what the application
needs to send feedback to the end-users. In that light, a PDF or font
library shouldn't expose any logging facilities at all or at least to
static logging that is externally configured.
Now, I know this has the potential to spark a heated debate again and it
raises question marks about the FOrayFont integration, but ATM I really
don't know what to do about it right now. I just realized we have a
problem here. I/we made promises on general@xmlgraphics.apache.org to
try to remove logging and other external dependencies (like Avalon) for
the common components because that's something which is very important
to the Batik side.
Maybe we could have two different implementations of the
PDFTextElementBridge so Batik can do native text rendering in a
different way than FOP but there's still the PDF library that depends
largely on the font subsystem. But maybe this could be handled in a
similar way. I need to investigate that a little more.
/me ducks.
On 03.09.2005 07:23:42 Victor Mote wrote:
> I just completed a project to make FOray's logging a bit more flexible. It
> now logs from an interface called org.axsl.common.PseudoLogger. Logging
> levels are the same as those for java.util.logging.Level (in Java 1.4 and
> higher), except that integrals are used instead of Level instances.
>
> I also wrote an implementation org.axsl.common.AvalonLogger, which FOray
> uses (for now) when it needs to *create* a logger. Since all loggers in the
> font system are supplied to the font system (instead of created within it),
> FOP should simply pass a different implementation to keep its logging
> consistent within itself. The AvalonLogger is a thin wrapper around an, er,
> Avalon ConsoleLogger, and is essentially an Adapter between the Avalon
> logging system and PseudoLogger. A similar approach can be used with
> whatever logging system FOP decides it wants to use. Writing the adapter
> should be fairly trivial, and it should be possible to use any logging
> system with this approach.
>
> I hope this makes the integration work a bit easier and the results more
> satisfactory to FOP. Please let me know if you have questions.
>
> Victor Mote
Jeremias Maerki
Re: Logging for FOrayFont
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
>>I'm satisfied with your explanations. Please just add a
>>LEVEL_DEBUG constant and I'm OK with your interface.
>
>
> OK, I have added the constant LEVEL_DEBUG back, and have also added a new
> one called LEVEL_TRACE.
> PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was
> equal to LEVEL_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST.
> These changes have been made to better accommodate what I understand the
> Commons Logging levels to be.
>
> This makes the Avalon mapping look like this:
> FINEST debug
> FINER debug
> FINE info
> CONFIG info
> INFO info
> WARNING warn
> SEVERE error
That's fine for me!
Thank you,
Vincent
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Vincent Hennebert wrote:
> Victor Mote a écrit :
> > Actually there is not a level named "debug", although I might have
> > defined that constant equal to "finest" in one of the
> earlier versions.
> This does not appear in CVS. I would suggest you to redefine
> such a constant to remove any ambiguity, as as you can see it
> confused me.
>
> > Here is the
> > way I mapped the Avalon levels in the AvalonLogger implementation:
> >
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/o
> > rg/axs l/common/AvalonLogger.java?view=markup
> >
> > FINEST debug
> > FINER info
> > FINE info
> > CONFIG info
> > INFO info
> > WARNING warn
> > SEVERE error
> Why not. Is I know now that debug corresponds to finest I'll
> follow the same scheme for commons Log.
>
> > I don't really feel strongly about it either, but perhaps a
> bit more
> > strongly than you for the following reasons:
> > 1. From a sheer "standard" aspect, I wanted to stay as close to the
> > Java logging system as possible. I would have used the
> > java.util.logging.Level instances (for type safety) instead
> of numeric
> > constants, except for trying to retain Java 1.3 compatibility.
> > 2. I prefer to allow for more granularity rather than less (within
> > reason), even if we don't think we need it right now.
> > 3. This is one of those things that you can change on
> Tuesday to make
> > one party happy, then change back again on Wednesday to
> make another
> > party happy, all for very little benefit. In short, there
> is no way to
> > make everyone happy.
> I understand your concerns and agree with them.
>
> >
> > Also, I don't know if you noticed the following methods:
> > info(String message)
> > warn(String message)
> > error(String message)
> > debug(String message)
> > which correspond directly to the Avalon methods of the same
> name, and
> > are intended to provide a sort of mapping for them.
> Certainly, but I also have to map the logMessage method...
>
> > I don't mind adding one more
> > called trace(String message) if that would make the mapping concept
> > more clear for you.
> Well, no need I think; as trace is below debug and debug is
> mapped to finest, there is no corresponding log level for trace.
>
> I'm satisfied with your explanations. Please just add a
> LEVEL_DEBUG constant and I'm OK with your interface.
OK, I have added the constant LEVEL_DEBUG back, and have also added a new
one called LEVEL_TRACE.
PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was
equal to LEVEL_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST.
These changes have been made to better accommodate what I understand the
Commons Logging levels to be.
This makes the Avalon mapping look like this:
FINEST debug
FINER debug
FINE info
CONFIG info
INFO info
WARNING warn
SEVERE error
Victor Mote
Re: Logging for FOrayFont
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Victor Mote a écrit :
> Actually there is not a level named "debug", although I might have defined
> that constant equal to "finest" in one of the earlier versions.
This does not appear in CVS. I would suggest you to redefine such a constant to
remove any ambiguity, as as you can see it confused me.
> Here is the
> way I mapped the Avalon levels in the AvalonLogger implementation:
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs
> l/common/AvalonLogger.java?view=markup
>
> FINEST debug
> FINER info
> FINE info
> CONFIG info
> INFO info
> WARNING warn
> SEVERE error
Why not. Is I know now that debug corresponds to finest I'll follow the same
scheme for commons Log.
> I don't really feel strongly about it either, but perhaps a bit more
> strongly than you for the following reasons:
> 1. From a sheer "standard" aspect, I wanted to stay as close to the Java
> logging system as possible. I would have used the java.util.logging.Level
> instances (for type safety) instead of numeric constants, except for trying
> to retain Java 1.3 compatibility.
> 2. I prefer to allow for more granularity rather than less (within reason),
> even if we don't think we need it right now.
> 3. This is one of those things that you can change on Tuesday to make one
> party happy, then change back again on Wednesday to make another party
> happy, all for very little benefit. In short, there is no way to make
> everyone happy.
I understand your concerns and agree with them.
>
> Also, I don't know if you noticed the following methods:
> info(String message)
> warn(String message)
> error(String message)
> debug(String message)
> which correspond directly to the Avalon methods of the same name, and are
> intended to provide a sort of mapping for them.
Certainly, but I also have to map the logMessage method...
> I don't mind adding one more
> called trace(String message) if that would make the mapping concept more
> clear for you.
Well, no need I think; as trace is below debug and debug is mapped to finest,
there is no corresponding log level for trace.
I'm satisfied with your explanations. Please just add a LEVEL_DEBUG constant and
I'm OK with your interface.
Regards,
Vincent
RE: Logging for FOrayFont
Posted by Victor Mote <vi...@outfitr.com>.
Vincent Hennebert wrote:
> What I liked with the Avalon Logger is the one-to-one
> correspondance between it and Commons' Log; commons just has
> one more level which is trace. So writing a Logger adapter
> that delegates logs to a Log instance is trivial.
>
> Now it's different because PseudoLogger has 7 log levels + 1
> debug level, whereas commons Log has 6 levels with different
> purposes. The best mapping that I see is the following:
> PseudoLogger -> Log
> finest trace
> finer trace
> fine trace
> debug debug
> config info
> info info
> warning warn
> severe error
Actually there is not a level named "debug", although I might have defined
that constant equal to "finest" in one of the earlier versions. Here is the
way I mapped the Avalon levels in the AvalonLogger implementation:
http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs
l/common/AvalonLogger.java?view=markup
FINEST debug
FINER info
FINE info
CONFIG info
INFO info
WARNING warn
SEVERE error
> Log's fatal level wouldn't be used. Writing an adapter in the
> other way would have been somewhat easier (and BTW
> corresponds to commons' Jdk14Logger).
>
> Personally I tend to find Commons log levels more intuitive
> and useful than the Jdk ones: I don't really know what to do
> with 3 fine, finer, finest and one config levels. May I
> suggest you to use Commons' style of levels instead?
>
> That said, this is by no means dramatic. For me it's just a
> matter of writing another wrapper.
I don't really feel strongly about it either, but perhaps a bit more
strongly than you for the following reasons:
1. From a sheer "standard" aspect, I wanted to stay as close to the Java
logging system as possible. I would have used the java.util.logging.Level
instances (for type safety) instead of numeric constants, except for trying
to retain Java 1.3 compatibility.
2. I prefer to allow for more granularity rather than less (within reason),
even if we don't think we need it right now.
3. This is one of those things that you can change on Tuesday to make one
party happy, then change back again on Wednesday to make another party
happy, all for very little benefit. In short, there is no way to make
everyone happy.
Also, I don't know if you noticed the following methods:
info(String message)
warn(String message)
error(String message)
debug(String message)
which correspond directly to the Avalon methods of the same name, and are
intended to provide a sort of mapping for them. I don't mind adding one more
called trace(String message) if that would make the mapping concept more
clear for you.
In short, it isn't a big deal to me either, but I would prefer to leave it
alone unless there is some compelling reason to change. When you say
"somewhat easier", we're talking about a pretty trivial difference, right?
Probably just 7 case statements instead of 5? If not, I will be glad to
rethink this.
> I agree that it's a bit cleaner if the font system has its
> own logging rules, independently of other existing logging
> systems. So no problem for me.
Yes, I thought this was pretty nice. The other thing it allowed me to do is
to make the FOray logging system very generic. I use the PseudoLogger
interface everywhere. When I need to instantiate a logger, I can use a
static method to do that. This means that I could switch over to a new
logging system for the price of changing the static method and writing a new
wrapper/adapter that implements PseudoLogger.
Victor Mote
Re: Logging for FOrayFont
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Hi Victor,
What I liked with the Avalon Logger is the one-to-one correspondance between it
and Commons' Log; commons just has one more level which is trace. So writing a
Logger adapter that delegates logs to a Log instance is trivial.
Now it's different because PseudoLogger has 7 log levels + 1 debug level,
whereas commons Log has 6 levels with different purposes. The best mapping that
I see is the following:
PseudoLogger -> Log
finest trace
finer trace
fine trace
debug debug
config info
info info
warning warn
severe error
Log's fatal level wouldn't be used. Writing an adapter in the other way would
have been somewhat easier (and BTW corresponds to commons' Jdk14Logger).
Personally I tend to find Commons log levels more intuitive and useful than the
Jdk ones: I don't really know what to do with 3 fine, finer, finest and one
config levels. May I suggest you to use Commons' style of levels instead?
That said, this is by no means dramatic. For me it's just a matter of writing
another wrapper.
I agree that it's a bit cleaner if the font system has its own logging rules,
independently of other existing logging systems. So no problem for me.
Vincent
Victor Mote a écrit :
> I just completed a project to make FOray's logging a bit more flexible. It
> now logs from an interface called org.axsl.common.PseudoLogger. Logging
> levels are the same as those for java.util.logging.Level (in Java 1.4 and
> higher), except that integrals are used instead of Level instances.
>
> I also wrote an implementation org.axsl.common.AvalonLogger, which FOray
> uses (for now) when it needs to *create* a logger. Since all loggers in the
> font system are supplied to the font system (instead of created within it),
> FOP should simply pass a different implementation to keep its logging
> consistent within itself. The AvalonLogger is a thin wrapper around an, er,
> Avalon ConsoleLogger, and is essentially an Adapter between the Avalon
> logging system and PseudoLogger. A similar approach can be used with
> whatever logging system FOP decides it wants to use. Writing the adapter
> should be fairly trivial, and it should be possible to use any logging
> system with this approach.
>
> I hope this makes the integration work a bit easier and the results more
> satisfactory to FOP. Please let me know if you have questions.
>
> Victor Mote
>