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
