RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Andreas L. Delmelle wrote: > Victor, IIC, Jeremias' concern is about the PDF lib in HEAD > containing substantial improvements over the code in the > maintenance branch. One aspect that springs to mind is WRT > encryption support --as I recall, maintenance still had some > problems with this, for instance, when using custom fonts... > Jeremias once mentioned that, in order to make it work > properly, he had to make significant changes to the PDF-related code. Yes, I am well aware that there are improvements to HEAD in several places, and that FOray will be missing those for the moment. I fully intend to eventually integrate the HEAD improvements into FOray, but 1) it is non-trivial, 2) I have bigger issues ATM (still trying to get FOTree isolated), and 3) I don't want to do much until I either have to, or until FOP decides how it will proceed -- if FOP decides to start with FOray's isolation work and upgrade to HEAD, then it might be a joint effort. If FOP decides to isolate HEAD's PDF lib directly, and if they use a common interface (like aXSL), then I shouldn't duplicate that effort in FOray, I should just wait until FOP is done with that work and drop it into FOray. If FOP doesn't want PDF isolated, or has no interest in using a common interface, then I'm not part of the picture at all. My main point to Jeremias is that none of this has anything to do with building an interface that everyone can use, except that: 1) FOray already has the interface at least partially designed by virtue of isolating the PDF code, and 2) making an interface *before* starting isolation work is a big help in that work. Victor Mote
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
> -Original Message- > From: Victor Mote [mailto:[EMAIL PROTECTED] > > Jeremias Maerki wrote: > Hi guys, (Just catching up on the postings of the last few days, this one caught my eye...) > > 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. Victor, IIC, Jeremias' concern is about the PDF lib in HEAD containing substantial improvements over the code in the maintenance branch. One aspect that springs to mind is WRT encryption support --as I recall, maintenance still had some problems with this, for instance, when using custom fonts... Jeremias once mentioned that, in order to make it work properly, he had to make significant changes to the PDF-related code. Greetz, Andreas
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
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
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
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 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?). Concerning the common end-user API, I'll publish my findings as soon as they are somewhat "presentable". Jeremias Maerki
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Jeremias Maerki wrote: > from the website I don't quite get the scope of the project. > That might have to be made clearer. Anyway, I didn't want to Yes, just as soon as it is totally clear to me :-) Right now, it boils down to "here are some things that I think could/should be shared, can anybody think of anything else?" > talk about it just yet, because it's not ready, but recently > I started writing a JAXP-like API for XSL-FO processors (I > called in JAFOP for now). It basically implements the ideas > we came up with in the API discussion over a year ago. In the > next few months I will probably need to integrate several > different FO-processors and want to have a common API for all. > Especially having a uniform API between FOP maintenance > branch and HEAD is important to me because I need to get FOP > 0.20.5 set up for PDF output and I will most probably need > the RTF output of FOP HEAD quite soon (all in the same VM, of > course). Also, the fact that we got 4 OS-FO-processors > screams for a common API so they can be used interchangeably. I think you are thinking API for the application as a whole. My vision for aXSL goes quite a bit deeper than that, trying to get a common API for the modules, IOW breaking the problem down into smaller pieces. My perfect world right now would have me using FOrayFont with RenderX. (That is not to say that FOrayFont is as good as RenderX's font handling -- it is not, yet anyway. But it means that I can get where I need to go more quickly with FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to aXSL, making FOray do so would seem to make it more usable to more people. And it at least gives hope to someone writing a piece that it might be pluggable with some other pieces. There was a thread several weeks ago that had to do with how to standardize extensions between the various applications, and Finn's work on Property binding was an indirect influence here as well. However, the main thing that started me down this path was thinking through the possibility of further modularization within FOray. Right now, for example, FOrayFont is totally independent of anything that looks like XSL-FO processing. But FOrayPDF is highly dependent on FOrayFont as are layout, the renderers, etc. It seemed like a desirable thing to pull out a layer of abstraction that lets FOrayPDF work, for example, with any other conformant Font system, or vice versa. Now, fonts and graphics are pretty easy. I can pull out an abstraction for fonts that has three interfaces, one of which is already written (it may need to get more complex later), and probably do a similar thing with graphics. FOTree is much more complex, and AreaTree has complexities for a different reason. > Can it be that we had the same idea at the same time again? > :-) Of course, having standardized validation messages and > such goes a bit beyond what I imagined, but that's ok. Actually, I don't envision standardized validation messages, although that would be OK. (I suppose you could even handle the multi-lingual aspects of that in a nice way.) I think that the original thread was dealing with how the exceptions should be thrown, and that *would* be a good thing to standardize, but different applications might want to handle them differently. I would characterize the two ideas as different, but very compatible, and thinking along the same general lines. What you have done with JAFOP could easily be a part of aXSL (or vice versa), and I would be glad to have you participate, when the appropriate time comes. Victor Mote
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor, from the website I don't quite get the scope of the project. That might have to be made clearer. Anyway, I didn't want to talk about it just yet, because it's not ready, but recently I started writing a JAXP-like API for XSL-FO processors (I called in JAFOP for now). It basically implements the ideas we came up with in the API discussion over a year ago. In the next few months I will probably need to integrate several different FO-processors and want to have a common API for all. Especially having a uniform API between FOP maintenance branch and HEAD is important to me because I need to get FOP 0.20.5 set up for PDF output and I will most probably need the RTF output of FOP HEAD quite soon (all in the same VM, of course). Also, the fact that we got 4 OS-FO-processors screams for a common API so they can be used interchangeably. Can it be that we had the same idea at the same time again? :-) Of course, having standardized validation messages and such goes a bit beyond what I imagined, but that's ok. On 04.11.2004 22:58:39 Victor Mote wrote: > Finn Bock wrote: > > > Do you mean that the 3 different processors should ideally > > report the same validation errors in the same manner? That > > can only happen after someone standardize a SAFO API (Simple > > API for FO parsing). Until then all implementation will throw > > different exceptions, which is fine by me. > > I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is > already taken, but at the time I registered the axsl.org domain, and I > finally went ahead yesterday and opened up a SourceForge project for it. > There isn't much content there now, and I doubt that anyone wants to spend > much time on it ATM, but we have a place to talk about such things for those > who are interested -- I think Joerg at least will appreciate it being > somewhere else, and I know there are others who are not interested as well. > It deals with more than just parsing and exceptions, but those are (or could > be) parts of it. Here is the website: > www.aXSL.org > > If FOP is interested, you are welcome to send a delegate, who will > automatically become a committer. Also, Peter West is welcome to be a > committer -- if we can accommodate his design, we'll sure try. I'll > eventually invite the commercial developers too, if it looks like there is > anything here that helps. Jeremias Maerki
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor, Thanks, I'll keep an eye on it. I'll drop by the forum as soon as I get a chance. (Busy with Defoe atm) Peter
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
I am impressed by your seemingly boundless dedication to XSL and its related fields. Glen --- Victor Mote <[EMAIL PROTECTED]> wrote: > > I actually toyed with this idea about two weeks ago. > IIRC, the SAFO name is > already taken, but at the time I registered the > axsl.org domain, and I > finally went ahead yesterday and opened up a > SourceForge project for it.