Jeremias Maerki wrote:

> Making these parts into separate components is in line with 
> what I have in mind when can talk about a shared repository 
> between Batik and FOP. I hope I can take a good look into 

Good. I think it has potential to be useful to many applications.

> what you did later. From a quick look, however, I wasn't very 
> pleased that you propose to use a lot of statics in the 
> "FontServer". I would prefer to have the possibility to 
> define multiple configurations in a heavy server environment 
> without having to go through the pains to separate multiple 
> environments using classloader magic. The system fonts are ok 
> like this, of course, but not the user-defined. Just my opinion.

I knew this would be controversial, and I'll be glad to consider changes.
The use case that you mentioned will, I think, be handled by some of the
other planned changes to configuration that are in the works. These changes
will be more client-centered than server-centered. So, rather than having
multiple servers configured different ways, each client will tell the server
more about what it wants, and the server will react based on this. However,
I may not see all of what you are thinking about here. If you can be more
specific, I'll think through this some more. One of the main purposes of
FontServer was to share as much of the Font overhead as possible between
documents in a heavy server environment, while keeping a light footprint in
the code. I actually tried to write it in a non-static way (with you in
mind) in the beginning, but it just ended up being silly, at least for the
purposes that it is currently designed for.

> Concerning the PDF library, I suggest you start from the PDF 
> lib in CVS HEAD instead of using the maintenance branch, even 
> if it means that the API may be a bit different. I've 
> invested a considerable amount of time to make the whole 
> thing better. Things such as encryption are much more cleanly solved.

First, in relation to FOP 0.20.5 (approximately FOray's starting place), the
changes that you are talking about are improvements, and I don't want to be
introducing changes or improvements yet. The goal here is really to make
sure nothing is broken. Then we can start making improvements, releasing
them, and getting user feedback.

Second, I *know* that, while in many ways HEAD is superior to the
maintenance branch, there are many specific instances where the maintenance
branch is superior to HEAD. I also know that there is no convenient list of
such items. I have to choose between the two evils of 1) losing benefit(s)
in the old code, and 2) losing benefit(s) in the new code. Of the two, I
prefer the latter. The user is not going to be happy if I remove his wheels
while installing the new, more powerful engine. Better IMO for us to upgrade
the engine in a manner that ensures that the wheels stay on. FOP is kind of
into the chasm thing, and FOray is definitely not.

Third, what you suggest is much easier said than done. I have made a note to
specifically check the encryption stuff when I get a chance. I suppose that
we can either diff the code (probably only useful to those who wrote it) or
use "missing feature" hunt. IOW, if we get to the place where we are
releasing code again, then, when issues come up on fop-user, hopefully you
or someone else will say "I already fixed that in HEAD", and we can
reconcile them. Ideally we want to get to the place where both branches are
using the same code. I *think* that is pretty easy for Fonts and Graphics,
but, as you say, probably not as easy for PDF, and probably PostScript too.

Victor Mote

Reply via email to