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 


> 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

Reply via email to