Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
On 31.07.2005 11:55:00 Simon Pepping wrote: On Sat, Jul 30, 2005 at 03:35:07PM +0200, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 15:35 --- Patch applied with some little modifications. Thanks a lot, Manuel! http://svn.apache.org/viewcvs?rev=226511view=rev I changed this to a notify mechanism, similarly to that already used in PSLM.activateLayout to notify the Root FO of the same. This gives a more direct access to the formatting results. Thanks! It would be a nice solution to let embedding apps register themselves as a FormattingResultsListener in the user agent. apps.Fop could do the same to present the user with the formatting results if he requires verbose output. I agree with the actual concept but I actually want something more general in the long-term. There are various aspects that I'd like to provide to embedders: - Number of pages over all and Number of pages for every page-sequence (obviously) - Callbacks on layout problems such as overflows, missing resources etc. (on which the listener can veto and therefore cause an exception.) [1] - Possibly additional hooks to insert images (via BufferedImage or providing a Graphics2D). We already have a stream insertion (or rather custom URI resolution) hook in FOUserAgent. Users have repeatedly asked for easy ways to do stuff like that. - there may be more. And! We need to split debugging output from verbose user information! Somehow. [1] Could be very interesting particularly for editor creators and people who want to be informed about every irrgularity in server-side mass document production. Every kind of problem should have an ID (machine-interpretation) and the error which go onto the log should also be i18n-ized (human-interpretation). Jeremias Maerki
Re: FOP Compliance Page was: getPageCount and FOP 1.0dev
On 02.08.2005 03:18:44 Manuel Mall wrote: Gentlemen, can we agree on the following? 1. The compliance page must be able to handle multiple FOP versions. Two, at most. 2. Which versions are shown at any point in time and how they are called will be decided on a case by case basis. Currently we are talking only about the last official release (0.20.5) and the current work in progress (1.0dev, 0.9pr, ...) but down the track versions may be added or removed at a frequency we don't know yet. VERY low frequency. As Chris said, don't worry about that too much. From my perspective, as I have put my hand up to do this, this raises two issues. a) What is the appropriate visual design for the compliance page to achieve 1.? Two proposals have been made: i) Maintain the current 3 column layout of Version Basic | Extended | Complete and replicate Version 1 Version 2 Basic | Extended | Complete | Basic | Extended | Complete This solution allows to quickly see by scanning down a column if a particular version is conformant at a particular level. However, it doesn't scale very well. Even with two versions only it will be very squished on the screen. Adding more than 2 will most likely be looking fairly awkward. ii) Change the layout to a single column per version and indicate in a single separate column at which conformance level a particular FO object or property lives (For a sample see the XSL-FO Object Support Table at http://www.arcus.com.au/fop/compliance.html). This solution scales better as it is more compact but it is harder to see if a particular version is conformant at a particular level. ii) should be good enough for now. b) What is the appropriate technical solution to achieve 2.? i) Manually edit the HTML ii) Use some WYSIWYG tool which can produce Forrest compliant output (OpenOffice was suggested) iii) Revive the generation of the page from XML input (does someone have the original compliance.xml file - I can't find it in SVN?) Go for i). No need to waste too much time. Obviously, iii) would be ideal as we'd have a separation of content and presentation but if it's not easily done, don't do it. I am happy to investigate and implement (if needed) the technical solution but I would like to get FOP committer feedback on the look feel of the page as this is part of the projects public face. Jeremias Maerki
Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)
On 01.08.2005 18:31:35 Andreas L Delmelle wrote: On Aug 1, 2005, at 11:37, Manuel Mall wrote: no argument from me against what you are proposing and also Joerg in [1]. We can still have a Driver.java for backwards compatibility for those who want to plug and play either in the product, or in a separate jar (fop-compat.jar?), or just here in BugZilla. Well, I've thought about that as well --keeping the Driver FTM as a sort of 'deprecated proxy' that simply forwards the method-calls to the respective components in the new API, but... IMO this is not an absolute necessity. If we decide on discontinuing support for the 0.20.5 API, then we may as well do it now. Right. People just don't like API changes and the path away from the Driver class a big break. The main point is however, that with the current design, implementing such a proxy looks rather clumsy --this has absolutely nothing to do with your coding, but is a consequence of the merging of component and standalone app... Right now, the Driver would have to be wrapped around the main-class, which is something I do NOT like :-/ I doesn't have to. The Fop class is so light-weight (if you think the main() method plus helpers away). You can easily reproduce that code if a few lines in that proxy. The following may make little sense to you, but just in case there are others following this thread: I VERY MUCH hope that there are! I feel that the class that will be used for running FOP from the command line should be an example in itself, in that it should use the component in the same way an embedding user would. Only difference is that the configuration will be created based on the command line parameters. I'm not fully happy either, especially, after I put in the classloader stuff. My proposal would be to do the same I did in Barcode4J: Let's create a cli package with the whole command-line stuff in there. See: http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/org/krysalis/barcode4j/cli/ Our CommandLineOptions class should build a Configuration which the main-class can then pass into the configure() method of the component. It really does not need to --or stronger: it shouldn't-- concern itself with initializing the OutputStream, for example. Roughly its tasks should be limited to: - tell the CommandLineOptions to construct a Configuration based on the parameters specified on the command line - tell the component to configure itself with that Configuration object - tell the component to go about its business (start() or run()) That class should, if I estimate correctly, be about 50 lines of code. Right now, we have a main() method in the Fop class at line 300+, which seems fishy to say the least. Yes, it's become too big to be of educational value. As a side note: Keep in mind that I've written a general API which easily handles calling FOP 0.20.5, FOP Trunk, JFOR, FOray and even Batik for the conversion of XSL-FO or SVG to PDF, PS, Print etc. It is designed to provide for the various XSL-FO implementations what JAXP is for Xerces, Crimson, Xalan, SAXON etc. The only problem is that I still don't have a name for it that doesn't produce any problems (JAFOP was too close to FOP to potentially scare commercial implementors away and JAXG, its current name, has been criticized by a Sun employee to be potentially problematic because of the use of the JAX prefix.) Jeremias Maerki
Re: svn commit: r226973
Adjusting verticals spaces (coming from space-before and space-after properties) in order to fill the region, whenever possible I have done a few tests before committing, with spaces on blocks and on lists (both in the list-block and in the list-items) and it seems to work; should you find bugs, just tell and I'll try and fix them. While I was making these changes, I noticed that the addAreas() methods for the block-level LM are, with few exceptions, very similar among each other, so sooner or later it could be nice to factor out a common method that they each would call. Regards, Luca
Re: rtflib independance from FOP
On 01.08.2005 16:57:28 guillaume wrote: Hello, While looking for a RTF text encoder (for accentuated characters), I gave a closer look at rtflib (in xml-fop_20050717162512.tar.gz). Uhm, I don't think we have current CVS snapshots anymore since we moved to Subversion some time ago. Seems to be a left-over that we need to get rid of. Please download the sources using Subversion. Subversion has the advantage over CVS that it works over HTTP and therefore passes most Firewalls and Proxies. It seems that here still a few dependancies on FOP in it. I understand it is not a priority for the FOP-Team right now, but if it can help in some way, here they are: - in rtfdoc.RtfGenerator there is a call to Fop.getVersion() juste to print the FOP version, and that obviously pulls all the FOP classes: this could easily be removed by adding a generator String parameter on the constructor (as the generator RTF metadata is optional, one could even keep the old constructor for compatibility) - in rtfdoc.BorderAttributesConverter: - fo.Constants is imported but it seems acceptable as it brings no other dependancy - fo.properties.CommonBorderPaddingBackground is imported but is only used by makeBorder(), which is not used anywhere in rtflib.**, so perhaps this could be alleviated too... Want to send a patch? :-) Sorry my dependancies checks are not fool-proof as I had neither eclipse nor grep to check, only Windows and few spare time to do it... I must had that I do not need a self-contained rtflib anymore right now, as what I needed is nicely self-contained in rtfdoc.RtfStringConverter: keep it that way if you can! :) I don't see why we couldn't. Good luck for the upcoming release! Thanks. P.S.: Please respond also to my address if possible as I have not subscribed to this list... We'd prefer if you would subscribe if you want to take part in the discussions. Thanks for your feedback! Jeremias Maerki
Re: svn commit: r226973
On 02.08.2005 11:18:18 Luca Furini wrote: Adjusting verticals spaces (coming from space-before and space-after properties) in order to fill the region, whenever possible I have done a few tests before committing, with spaces on blocks and on lists (both in the list-block and in the list-items) and it seems to work; should you find bugs, just tell and I'll try and fix them. Cool!!! I'll have a look at it. While I was making these changes, I noticed that the addAreas() methods for the block-level LM are, with few exceptions, very similar among each other, so sooner or later it could be nice to factor out a common method that they each would call. I can imagine. I guess there are many more of these areas. :-) Jeremias Maerki
Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
Jeremias Maerki wrote: I agree with the actual concept but I actually want something more general in the long-term. There are various aspects that I'd like to provide to embedders: - Number of pages over all and Number of pages for every page-sequence (obviously) - Callbacks on layout problems such as overflows, missing resources etc. (on which the listener can veto and therefore cause an exception.) [1] An important information for users producing book-style documents is, for each page, the difference between the available page heigth and the actual content height. Even if it is not a real error to create them, underfull pages are not beautiful. This information, that could be taken from the PageBreakPositions, would allow users to easily check if fop produced good pages without the need to open the pdf and look at it. Regards Luca
rtflib independance from FOP (continued) + JAFOG
1) - in rtfdoc.BorderAttributesConverter: - fo.properties.CommonBorderPaddingBackground is imported but is only used by makeBorder(), which is not used anywhere in rtflib.**, so perhaps this could be alleviated too... The same goes for the render.rtf.FOPRtfAttributes import. With this and all that was described in my previous message (subject: rtflib independance from FOP) an rtflib.jar (which I now eventually have a need for) can be build and used independantly from FOP! :) I can make a patch for that, but I need some feedback regarding the suggested interface addition and method removal, so please speak up! And also I am not really sure whether the most up-to-date version of rtflib lies in FOP or in JFOR... Could someone please clarify this? (Bertrand?) 2) Jeremias : what about JAFOG (Java API for Formatting Objects Generation)? -- Guillaume P.S.: All readers please appect my apologies for not responding on the right threads! (I have not subscribed to the ML (yet) as I can currently only read my mail from a web-mail ATM and believe me it is a real PITA...)
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 12:00 --- It seems that this happens, in particular, when the centered text is much shorter than the available width: for example, it is enough to add a 2cm start- and end-indent to the first block to have its text placed in a single line. Note that the 1.0 dev version creates *3* lines for that block: one with Victorian Land Index Property Address, the second with Search Result and a third empty (or so it seems) line. I think this could have something to do with the restarting mechanism in the breaking algorithm. I'll try and have a closer look at what happens during the line breaking of this block. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: rtflib independance from FOP (continued) + JAFOG
On 02.08.2005 11:44:23 guillaume wrote: 1) - in rtfdoc.BorderAttributesConverter: - fo.properties.CommonBorderPaddingBackground is imported but is only used by makeBorder(), which is not used anywhere in rtflib.**, so perhaps this could be alleviated too... The same goes for the render.rtf.FOPRtfAttributes import. With this and all that was described in my previous message (subject: rtflib independance from FOP) an rtflib.jar (which I now eventually have a need for) can be build and used independantly from FOP! :) I can make a patch for that, but I need some feedback regarding the suggested interface addition and method removal, so please speak up! As long as you preserve the existing functionality, you're free to propose any changes. If the RTF library is useful without XSL-FO, that's absolutely fine and we can make sure in the future that it stays that way. And also I am not really sure whether the most up-to-date version of rtflib lies in FOP or in JFOR... Could someone please clarify this? (Bertrand?) JFOR has been integrated in FOP, so FOP is not the most up-to-date version. 2) Jeremias : what about JAFOG (Java API for Formatting Objects Generation)? Thanks for the suggestion. However, formatting objects generation sounds almost like we're generating FO, not that we consume FO, and in the meantime the API can do more than just consume XSL-FO. It can handle any XML-based format which produces graphical output (like XSL-FO, SVG, MathML, you name it). -- Guillaume P.S.: All readers please appect my apologies for not responding on the right threads! (I have not subscribed to the ML (yet) as I can currently only read my mail from a web-mail ATM and believe me it is a real PITA...) Poor guy. I heard some people are quite happy with accessing lists through GMANE (http://gmane.org/) but I haven't tried it myself. Jeremias Maerki
Re: rtflib independance from FOP
Uhm, I don't think we have current CVS snapshots anymore since we moved to Subversion some time ago. Seems to be a left-over that we need to get Well, I took it from http://svn.apache.org/snapshots/ so the name would be quite misleading. And it seems not to be left-over as cocoon-2.2 is also featured here, and is IIRC younger than the Cocoon CVS-to-SVN transition... rid of. Please download the sources using Subversion. Subversion has the advantage over CVS that it works over HTTP and therefore passes most Firewalls and Proxies. I will try. Want to send a patch? :-) Sure, as long as the issues summed up in my other message are OK! Would a [PATCH] rtflib independant from FOP bug in Bugzilla (with attachement done with diff -u with xml-fop/ as base directory) would do? We'd prefer if you would subscribe if you want to take part in the discussions. I understand that, but for the reasons described in my other message I'd rather not for the moment... Thanks for your feedback! You're welcome. After (ab)using FOP so much it's time to give back for me! :)
Re: rtflib independance from FOP (continued) + JAFOG
Jeremias Maerki wrote: snip/ And also I am not really sure whether the most up-to-date version of rtflib lies in FOP or in JFOR... Could someone please clarify this? (Bertrand?) JFOR has been integrated in FOP, so FOP is not the most up-to-date version. Is this a typo, or did you mean to say FOP is *not* the most up-to-date place for thr RTF Renderer? I thought the JFOR project had stopped and since integrating the RTF Renderer into FOP, several improvements had been made to the RTF Renderer in FOP. snip/ Chris
Re: rtflib independance from FOP (continued) + JAFOG
Uhm, oops, yeah, sorry! Of course. Thanks for spotting that mistake. On 02.08.2005 12:36:41 Chris Bowditch wrote: Jeremias Maerki wrote: snip/ And also I am not really sure whether the most up-to-date version of rtflib lies in FOP or in JFOR... Could someone please clarify this? (Bertrand?) JFOR has been integrated in FOP, so FOP is not the most up-to-date version. Is this a typo, or did you mean to say FOP is *not* the most up-to-date place for thr RTF Renderer? I thought the JFOR project had stopped and since integrating the RTF Renderer into FOP, several improvements had been made to the RTF Renderer in FOP. snip/ Chris Jeremias Maerki
Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
I've put all this on the Wiki. http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback On 02.08.2005 11:36:59 Luca Furini wrote: Jeremias Maerki wrote: I agree with the actual concept but I actually want something more general in the long-term. There are various aspects that I'd like to provide to embedders: - Number of pages over all and Number of pages for every page-sequence (obviously) - Callbacks on layout problems such as overflows, missing resources etc. (on which the listener can veto and therefore cause an exception.) [1] An important information for users producing book-style documents is, for each page, the difference between the available page heigth and the actual content height. Even if it is not a real error to create them, underfull pages are not beautiful. This information, that could be taken from the PageBreakPositions, would allow users to easily check if fop produced good pages without the need to open the pdf and look at it. Regards Luca Jeremias Maerki
[EMAIL PROTECTED] KO?
It seems that [EMAIL PROTECTED], which is what gmane.org uses (see http://gmane.org/list-address.php?group=gmane.text.xml.fop.devel), does not exist anymore...---BeginMessage--- Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 90279 invoked by uid 99); 2 Aug 2005 14:54:15 - Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Aug 2005 07:54:15 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of [EMAIL PROTECTED] designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Aug 2005 07:54:05 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dzy6u-0006px-53 for [EMAIL PROTECTED]; Tue, 02 Aug 2005 16:51:18 +0200 Received: from lns-vlq-17f-81-56-174-131.adsl.proxad.net ([81.56.174.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Tue, 02 Aug 2005 16:51:16 +0200 Received: from guillaume by lns-vlq-17f-81-56-174-131.adsl.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Tue, 02 Aug 2005 16:51:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: [EMAIL PROTECTED] From: Guillaume =?utf-8?b?RMOpZmxhY2hl?= [EMAIL PROTECTED] Subject: Re: rtflib independance from FOP (continued) + JAFOG Date: Tue, 2 Aug 2005 14:49:57 + (UTC) Lines: 35 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: [EMAIL PROTECTED] X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.56.174.131 (Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.8) Gecko/20050511 Firefox/1.0.4) Sender: news [EMAIL PROTECTED] X-Virus-Checked: Checked by ClamAV on apache.org Please continue on the other thread from now on, I'm trying to close this one! ;) Jeremias Maerki dev.jeremias at greenmail.ch writes: As long as you preserve the existing functionality, you're free to propose any changes. If the RTF library is useful without XSL-FO, that's absolutely fine and we can make sure in the future that it stays that way. OK. JFOR has been integrated in FOP, so FOP is no[w] the most up-to-date version. OK, now I just need to use SVN or get the confirmation that the snapshots are current before preparing a first patch. Jeremias : what about JAFOG (Java API for Formatting Objects Generation)? Thanks for the suggestion. However, formatting objects generation sounds almost like we're generating FO, not that we consume FO, and in the meantime the API can do more than just consume XSL-FO. It can handle any XML-based format which produces graphical output (like XSL-FO, SVG, MathML, you name it). JAGUX: Java API for Graphics Using XML? Time to start a contest for more imaginative people I guess! :) Poor guy. I heard some people are quite happy with accessing lists through GMANE (http://gmane.org/) but I haven't tried it myself. This is a test BTW! ;) Many thanks for the suggestion, it seems to work well! ---End Message---
Re: [EMAIL PROTECTED] KO?
Interesting. [EMAIL PROTECTED] never existed. At first, it was fop-dev@xml.apache.org and now it's [EMAIL PROTECTED] Maybe you need to notify the GMANE admins. I don't know how this works. I'm not using it but I heard others being happy with GMANE (but on other mailing lists). On 02.08.2005 17:19:41 guillaume wrote: It seems that [EMAIL PROTECTED], which is what gmane.org uses (see http://gmane.org/list-address.php?group=gmane.text.xml.fop.devel), does not exist anymore... Jeremias Maerki
Re: Element list generation for tables (special case)
Thanks Simon. Now I understand. I've just committed the general fix for the problem (I think), but have hard-coded the penalty value to 900 for the moment. I think your idea might be interesting but I'm a little clueless about the right formula to calculate an appropriate penalty value. I'll leave that for someone more mathematically gifted. :-) The code line is clearly marked with a TODO item if anyone wants to try. I'm happy enough with the result. :-) On 31.07.2005 12:17:31 Simon Pepping wrote: On Sat, Jul 30, 2005 at 03:46:31PM +0200, Jeremias Maerki wrote: Sorry, but I have trouble understanding what you mean. Could you please elaborate with an example? Thanks. On 30.07.2005 13:54:25 Simon Pepping wrote: On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote: I was under the impression that the breaker automatically favors break decisions that take up less space. It even goes so far that if you have a minimum=0pt and an optimum=2opt on a space-before, that it currently chooses 0pt which is not so good, actually. Penalties would help. If there were a penalty associated with the break below 'B', then the break above it becomes more favourable. I do not think the breaker could do that otherwise (without the newly proposed rule). If there were a penalty value associated with a break that makes the table longer, e.g. 0.1 * w, then the following list would result: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=960 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 Now a break at 12 would have 960 demerits. A break at 10 would have 0 demerits, but because it would have less content on the page it would have a larger stretch and that would itself associated demerits, say 500. Then the break at 10 would be selected. In general, the table breaker may select breaks with a skew placement of table contents, e.g. xxx | | --|- | xxx' | yyy over breaks with a more even placement of table contents, e.g. xxx | yyy' | --|- | xxx' | yyy Such breaks are rather ugly. They also make the table considerably longer. One can use the extra length of the table as a measure of skew placement and thus of ugliness and of the penalty value associated with this break. This makes that breaks with a skew placement of content are disfavoured, and only selected when more even breaks have lots of demerits themselves, due to other causes. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class
Manuel Mall wrote: [snip] Makes sense to me. Actually this is exactly what the 0.20.5 Fop.java does. Well, I'd rather refrain from reintroducing a ComandLineOptions like class. I'd still say the most intuitive setup would be - API classes as usual (FO processor, configuration, maybe interfaces and implementations for input and output of the FO processor) - A single CLI class with a main() method and possibly a few more methods for better structuring which parses the command line (maybe using commons CLI), sets up a configuration as well as input and output for the FO processor (possibly using an XSLT in the input pipeline), instanciates a FO processor, runs it, and performs clean up. - A sample servlet class roughly doing the same - etc. There is no need for the sample CLI class and the servlet class to be small. I can't see how a CommandLineOption class or parsing command line options can be reused elswhere. J.Pietschmann
Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)
On Aug 2, 2005, at 11:14, Jeremias Maerki wrote: On 01.08.2005 18:31:35 Andreas L Delmelle wrote: ... Right now, the Driver would have to be wrapped around the main-class, which is something I do NOT like :-/ I doesn't have to. The Fop class is so light-weight (if you think the main() method plus helpers away). You can easily reproduce that code if a few lines in that proxy. Yeah, seems I was jumping the gun a bit... After all, it's 300+ lines, only if you count all comments and whitespace :-) snip / I'm not fully happy either, especially, after I put in the classloader stuff. My proposal would be to do the same I did in Barcode4J: Let's create a cli package with the whole command-line stuff in there. See: http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/ org/krysalis/barcode4j/cli/ Funny, right before I read your reply and without having looked at Barcode4J, that was EXACTLY what I was thinking about. That way, it becomes possible to build a JAR without the CLI classes, for people that hardly ever use FOP from a console. Those that need only occasional runs via CLI need simply an additional jar on their classpath that contains only FOP's CLI classes. It's not that there are many, but still, for the purists this means that they don't need to contaminate their environment with those classes (that are not re-usable in other contexts: see Joerg's remark earlier on). Plus: separating the CLI means that we're more at liberty to add dependencies there without forcing our API-users to drag them in as well. (Ideas? Still a wild one ATM, but Jakarta Commons' Launcher seemed interesting: IIC, it can be used to handle the tasks we now deal with in our startup scripts --which would mean that we have to maintain that stuff only in one place--, offers fine-grained control over the class-loading.) snip / As a side note: Keep in mind that I've written a general API which easily handles calling FOP 0.20.5, FOP Trunk, JFOR, FOray and even Batik for the conversion of XSL-FO or SVG to PDF, PS, Print etc. Yes, I remember. Of course, that is one side: a matter of conforming to a set of interfaces. How we implement them and map the general API to our own is another. One thing's for sure: such mapping will be much easier if our specific API is neatly designed, regardless of what the general interfaces look like. I'm very much in favor of the idea, and my preference in that area is towards a *very* abstract and stringent general API, even if that would mean that for all of the above apps someone still needs to code API-to-API (specific-to-general) bridges. Evidently, there can be absolutely no references whatsoever to any of those particular applications in the general API --ideally it should be designed by someone who knows nothing about those particular apps' usage patterns, but who understands what a FO or SVG processor is/does (besides being very proficient in Java interface-design, of course :-)) It is designed to provide for the various XSL-FO implementations what JAXP is for Xerces, Crimson, Xalan, SAXON etc. After all, I'm currently wondering if Xalan or SAXON ever started out as an attempt to write an implementation for JAXP, or if their initial concern was to code a decent XSLT processor and they added the JAXP conformance further on. (I'd guess it lies more in the direction of the latter, but I'm not sure at all) And, now that JAXP is mentioned: of course, it's beneficial to expose that API's functionality in our own --after all, it's *XSL*-FO--, however, we should probably allow a number of possibilities, ranging from: URL srcFileloc, URL xslFileloc, URL tgtFileloc --we could determine the output target from tgtFileloc's extension (in a lot of situations) over File srcFile, File xslFile, File tgtFile over users passing in their own InputSources, Transformers and OutputStreams, or in the end maybe even Source src, Style style, Target tgt --where those three are our own independent interfaces, and user-developers can code their own customized implementations. As long as their objects know how to produce sensible answers to FOP's questions, it will render them as specified. This abstraction is more or less based on our Obj2PDF example, but precisely that example would become much much simpler. [Think of a Processor, without XML, XSLT or FO: Object-over-Object-to-Object] I have a feeling that such an approach would greatly simplify the eventual idea of a pluggable Renderer framework --Target as a class that is able to return a component that conforms to our most basic Renderer interface. Setting it through a RENDER_TYPE constant will be for convenience only. Especially the simpler ones are important --for rookie Java developers--, since *ours* is the XML API, but the users-embedders' shouldn't necessarily be. If they're interested and clever enough, they will be
