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))
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: FOP Web Site Update
On Oct 16, 2004, at 12:03 PM, Clay Leeds wrote: My intention is to bring xml-fop up-to-date next week (I'll be out of town this weekend). Well, it didn't happen next week or even the week after. Getting the FOP Standards Compliance page[1] up to snuff has been, shall we say... challenging. But I've finally got content (the table of 'compliance'!) displaying. Unfortunately, we're still not there, as the link portion (which serves as a veritable Table of Contents for the table) is not being generated yet. More importantly, the color-code system isn't working yet, either (the bgcolor is always 'white'). Also, the Citation links are not generated either. These should all prove relatively simple to resolve (especially if I had some help from someone who knows how to make that portion work: are you listening Keiron, Glen or Christian ;-) wink!). Or, I could just continue plodding through the muck and see if I can figure it out. Finally, there are a bunch of files in alt.design which don't render content. Considering the fact that alt.design may be moving on to Defoe[3], that problem may be moot (don't worry, Peter! I intend to help you get your content working... it just may not be a part of the new and improved FOP web site 'launch'). For the current state of the FOP web site, you can always point your browser to: http://homepage.mac.com/webmaestro/xml-fop/ [1] http://xml.apache.org/fop/compliance.html [2] http://homepage.mac.com/webmaestro/xml-fop/compliance.html [3] http://defoe.sourceforge.net/ Web Maestro Clay -- Clay Leeds - [EMAIL PROTECTED] Webmaster/Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: commenting the Knuth code/centering issue
On Thu, Nov 04, 2004 at 02:59:52PM -0800, Glen Mazza wrote: --- Luca Furini [EMAIL PROTECTED] wrote: [BTW, I'm considering getting that Digital Typography book by Knuth you had mentioned earlier. Do you recommend it? (I was thinking that given all the time I spend on FOP I should start looking a little more at the scientific aspects of this work.)] I have it. The chapter on the line breaking algorithm is very enlightening. Simon -- Simon Pepping home page: http://www.leverkruid.nl
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: XMLGraphics temp site up (was Re: Can we please disable the Wiki on Nagoya?)
[Clay] More thoughts and comments? One site that may serve as a source for more ideas is the Apache Web Services TLP: http://ws.apache.org/. Glen
Re: FOP Web Site Update
Clay Leeds wrote: Well, it didn't happen next week or even the week after. Getting the FOP Standards Compliance page[1] up to snuff has been, shall we say... challenging. But I've finally got content (the table of 'compliance'!) displaying. Unfortunately, we're still not there, as the link portion (which serves as a veritable Table of Contents for the table) is not being generated yet. More importantly, the color-code system isn't working yet, either (the bgcolor is always 'white'). Also, the Citation links are not generated either. These should all prove relatively simple to resolve (especially if I had some help from someone who knows how to make that portion work: are you listening Keiron, Glen or Christian ;-) wink!). Or, I could just continue plodding through the muck and see if I can figure it out. The compliance page is quite difficult to understand, IIRC one needs to be fairly knowledgable about Cocoon sitemaps. But I last looked at it before I was a committer. I don't think the colors/sorting by compliance level are that important, however. The XSL spec lists each FO (and property, I believe) in terms of one of three compliance levels--but we don't need to duplicate that information on this page anymore. I think most people go to this page to determine if property X or formatting object Y is available, regardless of its listed compliance level in the specification. [BTW, If you can change to the bright red color for the mouse-hover like the Web Services TLP has that would be nice.] One thing perhaps we should change sometime, is to remove/replace our leading graphic on our home page [1]. For a newbie to XSL, it looks silly: See with FOP, you need to create 75 lines of XSL in order to get one line of output! Hopefully we will have something better to replace it with in the future. Thanks, Glen [1] http://homepage.mac.com/webmaestro/xml-fop/images/document.jpg
