Arved et al, To clarify further: there are three re-design efforts going on. Keiron & Karen in Java, building on the existing code base. Arved doing a ground-up redesign in Perl (protptyping) and C or C++, as he has discussed. Me, in Java, doing a ground-up.
Do not despair. If Flannery O'Connor is to be believed, Everything That Rises Must Converge. I believe that these design efforts will, if not converge, at least cross-fertilise one another considerably. You will probably have noticed that there is a lot of cross-talk between the principals. At the end of the day, I think that the best ideas will shake together in the bottom of the pan. However, I would hope for more. I can conceive of no reason why a common design will not work in Java, C, C++, Perl or any other language of choice. Implementation details may differ, but the same overall design should be realisable in any useful language. In that sense, I disagree with Arved. I think his work *is* contributing to the redesign of FOP. Obviously, I think mine is too. So, if you decide to get involved in xslfo-proc, the effort will not be wasted in terms of helping bring FOP to completion. Let me just strongly endorse Arved's comment about the oxymoronic "UML design", as in "design by UML". What a bizarre idea. It must be something consultants do. Peter Arved Sandstrom wrote: >Hi, Matt > >Let me clarify. The redesign is what Keiron & Karen (primarily) are working >on. It is a redesign for FOP. > >What I started last fall is another project, which is intended to produce a >C/C++ XSL-FO formatter. This is called xslfo-proc, and is on Sourceforge. ... > >I did enough UML design last fall to realise that that was a waste of time. >So a month ago I started working on a Perl prototype. I uploaded the first >code yesterday ... I expect >to have some pretty good layout happening within a month. > >I have no intentions of abandoning FOP, but the redesign for FOP was and is >critical, and only so many people can usefully do that - two max, IMO. ... I am >devoting most of my efforts to > >xslfo-proc - it has a different approach and I hope it complements FOP >rather than competes with it. > >I'll second one specific comment of Peter's very strongly. I also believe >that an XSL formatter project that is going to succeed has to tackle the >whole problem. Formatting is not very modular, in other words. Not >everything needs to be implemented right away but it sure needs to be >considered, and a place for everything needs to be built in. The existing >FOP shows us that retrofitting doesn't work. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
