Jeremias Maerki wrote: > Ah, now I'm starting to see where this is going. I think this > something extremely difficult to do. To a certain degree it
Agreed. > sounds like my ideas/plans for the XML Graphics project, > namely to separate certain peripheral components (fonts, PDF > lib, Graphics2D implementations etc.) from FOP so efforts can > be pooled between projects where easily possible (i.e. > without major religious wars). For example, Peter is quite > interested in the Graphics2D implementations. But going to a > level of detail you hint at (at least that's my impression) > will prove really difficult. You know I'm all for > componentization, but you may have too high hopes here. But I > could be wrong. Don't spend too much time explaining this to > me. :-) We'll just see what happens. I will monitor what's The "standards" themselves do not need to be monolithic. So maybe one implementation implements only aXSL-Font (I'm making this up as I go), while another might implement all of them. The idea is that one more axis of benefit is added into the product mix. Assume that modularization is even possible, which is yet to be proved, at least by any of the open-source implementations of which I am aware. Assume also that, all other things being equal, it is a desirable trait, not just for the developer, but for the end user. If these are both true (and I think they are), a product that chooses *not* to implement it would presumably want to have a really good reason for not doing so. Defoe's reason might be superior performance (as I understand it), which is quite possible, and FOP's might be a quicker time-to-market (as I understand it), also quite possible, at least starting from today. If *setting* a standard devolves into a religious war, we should probably abandon the effort. However, I don't know that it needs to. When you think about it an API for the FOTree, for example, the standard almost writes it for you. > going on. So, we're still going in the same general direction > although I'm still a bit concerned that you based your PDF > part on the maintenance branch code (that's still the case, > isn't it?). FOrayPDF is based on the maintenance branch code, but I am not sure I understand your point. I assume you are thinking of how to get a PDF-library created in the new Graphics project? If I understand where you are headed, you have to either duplicate in HEAD the work that I have done in isolating it, or you have to duplicate the changes made since FOP forked itself. Since it is in FOray's interest to have the better PDF library available, I might do the latter -- it is just a matter of priorities & right now finishing the modularization is more important (to me). And since PDF is a relatively discrete part of the system, it may not be too hard to do. If you guys decide to do the former, having the aXSL APIs in place would be a very valuable tool in that process. I'll be glad to explain why when you are ready to look at it, and perhaps I'll have something concrete (about the abstractions :-) to show you by then as well. I'll be very happy to try to coordinate this stuff so that we don't duplicate effort -- there has been and will be too much of that as it is. Victor Mote
