Re: Ensuring integrity searchability of ML archives (was Re: [REQUEST] XML Graphics setup) (Modified by Clay Leeds)
Clay Leeds wrote: When the Apache Forrest project changed to a new domain, they also changed from [EMAIL PROTECTED] to [EMAIL PROTECTED] [EMAIL PROTECTED] Unfortunately, with this change comes (IMHO) a significant problem for browsers of the archives: forrest-dev@ mail is a completely separate mailing list (with a separate interface). The problem is that forrest-dev was used for *all* dev ** user mailing list traffic, so a search in the 'current' mailing lists' archives does not include content in forrest-dev (that's a separate search). Which archives are you looking at? The eyebrowse archives include the [EMAIL PROTECTED] and go back to November 2002. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=datefrom=2002-05-01to=2002-05-31first=1count=636 For Eyebrowse, when moving a list name, we generally set up a new archive under the new list name and index all the old messages into the new archive. Cheers, Berin
[GUMP@brutus]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-02112004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-02112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-02112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-02112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-02112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-02112004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-02112004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - junit: [javac] Compiling 31 source files to /home/gump/workspaces2/public/workspace/xml-fop/build/test-classes [javac] This version of java does not support the classic compiler; upgrading to modern [javac]
Re: AreaFactory patch
Glen Mazza wrote: snip/ Personally speaking, I am much more amenable to adding some complexity (LM Makers, for example, or opening up our validation) if it helps out Finn's work, because of the sheer weight of contributions he adds to Fop. (We slow him down, we slow down Fop.) Making these changes for someone who isn't submitting contributions, however, is less of a concern for me. If a user is going to propose a change that would slow down system development, we should be getting some work to compensate for it, at least during this time while we are still building the system. My inclination is to have him place this patch in Bugzilla, and let's wait until we have others requesting it (vs. those who would rather have LM's pluggable.) In the meantime, I think it would be best for everyone to keep layout as simple as we can until it is done. I am open to others' opinions however. I'm definitely in agreement with you on this one Glen. Lets keep Layout simple whilst its still unfinished. Pluggable LMs can be added once we have an initial release. Chris
Re: Form Extension
Clay Leeds wrote: On Oct 31, 2004, at 7:17 AM, Florian Hecht wrote: I' ve developed a form extension for XSL-FO for an university project. It's an extension to FO like the fox extensions. With it you can declare and define the usual form elements like edit fields, radio buttons, check boxes, combo boxes, list boxes, comment fields and buttons. They are inserted into a document as inline objects, so that they flow like normal text. As a proof of concept I've extended fop-0.20.5 to support my form extension. I'm using the system around ExtensionObj to make fop understand my elements and I've extended the PDFRenderer to generate PDF documents that contain forms, that can be filled out and submitted just like normal HTML forms. This is an oft-requested (once every couple of months counts as 'oft-'...) feature. Thank you for this information! This is exciting, and I can imagine it almost certainly being a tool others may want. Hi Clay - yes I concur with you. This feature is asked for quite frequently by some of our clients. snip/ The reason why I'm announcing this is that I will finish the project in a couple of days and I don't think I will develop the form extension any further. Maybe someone will find the sources usefull as a starting point or is even willing to develop it further. The sources and the precompiled jar archive can be found at my homepage [1]. I've also got an example fo document with my extension there, together with the resulting PDF file. So anyone who's interested can take a quick look at it. The paper I'm writing on this project will be released in couple of days (in German though, Studienarbeit) together with a little documentation on the form extension in English. I just wanted to let you know. If you have any questions, just ask me. Any feedback is welcome. Thanks for letting us know. I am mildly excited about this. However, I fear I wont be able to use it unless it is ported to HEAD. Thanks, Chris
Re: Ensuring integrity searchability of ML archives (was Re: [REQUEST] XML Graphics setup) (Modified by Clay Leeds)
On Nov 1, 2004, at 1:11 PM, Berin Lautenbach wrote: Clay Leeds wrote: When the Apache Forrest project changed to a new domain, they also changed from [EMAIL PROTECTED] to [EMAIL PROTECTED] [EMAIL PROTECTED] Unfortunately, with this change comes (IMHO) a significant problem for browsers of the archives: forrest-dev@ mail is a completely separate mailing list (with a separate interface). The problem is that forrest-dev was used for *all* dev ** user mailing list traffic, so a search in the 'current' mailing lists' archives does not include content in forrest-dev (that's a separate search). Which archives are you looking at? The eyebrowse archives include the [EMAIL PROTECTED] and go back to November 2002. http://nagoya.apache.org/eyebrowse/BrowseList? [EMAIL PROTECTED]by=datefrom=2002-05-01to=2002-05 -31first=1count=636 For Eyebrowse, when moving a list name, we generally set up a new archive under the new list name and index all the old messages into the new archive. Cheers, Berin Sorry. I guess I'm having trouble explaining this. Because [EMAIL PROTECTED] was the only list for a long time, it was used for Forrest DEV issues ** for Forrest USER issues. When the Forrest was made an Apache Top-Level-Project (http://forrest.apache.org) they decided to split the list into [EMAIL PROTECTED] and [EMAIL PROTECTED] The problem is that all of the USER-related information in the old [EMAIL PROTECTED] is inaccessible to a query by a someone searching the [EMAIL PROTECTED] mailing list archives. The solution (IMO) is to copy the [EMAIL PROTECTED] information in to the [EMAIL PROTECTED] mailing list archives (I realize it's already copied to the [EMAIL PROTECTED] archive). (NOTE: I want to reiterate that I'm not requesting this change be done as I'm not a Forrest Committer and this has not been discussed on [EMAIL PROTECTED]). I just want to ensure the integrity of fop-dev fop-user lists remain intact during the switch from [EMAIL PROTECTED] to [EMAIL PROTECTED] It sounds like both archives can be merged, so this should not be a problem for XML Graphics. 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: Form Extension
I went to that page, but the PDF link doesn't work. The link is fixed. It should work now (http://wwwstud.ira.uka.de/~s_hecht/) Before you post on fop-user perhaps you/we should transfer it to a more 'permanent' server (since your e-mail will be in the FOP archives in perpetuity). I'm thinking that a good to place for this extension is on the 'Objects For Formatting Objects' Sourceforge project page[2] (assuming that Simon Pepping and/or other FOP committers agree). However, before we do that, we need to ensure it has the proper licensing. Please go to Apache Software Grants page for information on how to transfer[3]. I think it is a good project to be hosted by the OFFO project. The purpose of the OFFO project is to keep FO-related OS projects available for users and prospective developers. In view of the fact that you do not wish to develop it further, it should work out of the box for fop-0.20.5. Are you willing to answer questions from users? Sounds good to me to put it into the OFFO Project. As it is my 'baby' I'm of course willing to answer any questions about it. It would be good if you have some developer documentation, to give a prospective maintainer a headstart. The paper is nearly completed. It contains some indepth description of the implementation, but it will be only available in German. I think I will translate this section to English and some starting information. So that someone who want's to tinker with it knows where to start. It would be best if you release it under the Apache2 License. However, OFFO is able to host projects under any OSI approved Open Source license. You need to send the grant to me as the project maintainer; I will deposit it with the OFFO project. I'm rather busy this week, so you'll have to give me a week or so to review the licence and grant stuff. This would be my first open source contribution, so I want to do things right. Note that I am not offering to do maintenance or to learn enough about the project to answer user questions. Currently OFFO does not have CVS services, but they can be set up if there is an interest. You can direct people to me for questions. No Problem. From Clay Leeds: Also, as you are probably aware, fop-0.20.5 (the fop-0_20_2-maintain branch) is a dead-end (it's in code freeze so FOP development can focus all energies on the FOP 1.0 release). It would be *HUGE* (!) if you could 'port' your work over to the 1.0-dev (HEAD branch). Since you are intimately aware with the inner workings of your code, no one will be able to do this more efficiently or effectively. I've taken a quick look at the HEAD branch: Adding the new fo-elements and the necessary PDF objects and PDFRenderer functions should be straight forward. But I had to make some ugly hacks, in order to actually make this work with FOP. I definitely think it's possible to integrate it into HEAD, but it would require work on my side. At the moment I'm relatively busy with my studies. But when I find some time, I might take it up again. It's good to here that there is interest in the ability to generade PDFs with forms, but I can't promise anything. Sorry. Web Maestro Clay Regards, Simon Big thanks for the feedback. It's nice to see that others are interested in one's work. Cheers, Florian
Re: Form Extension
Simon Pepping wrote: On Mon, Nov 01, 2004 at 08:50:06AM -0800, Clay Leeds wrote: Florian, On Oct 31, 2004, at 7:17 AM, Florian Hecht wrote: Hi FOP devs, I' ve developed a form extension for XSL-FO for an university project. It's an extension to FO like the fox extensions. With it you can declare and define the usual form elements like edit fields, radio buttons, check boxes, combo boxes, list boxes, comment fields and buttons. They are inserted into a document as inline objects, so that they flow like normal text. As a proof of concept I've extended fop-0.20.5 to support my form extension. I'm using the system around ExtensionObj to make fop understand my elements and I've extended the PDFRenderer to generate PDF documents that contain forms, that can be filled out and submitted just like normal HTML forms. At the moment the module for fop consists of a jar archive with the classes and a new batch file to start the processing (I'm not using the fop class as a starter, because I need to create a different renderer). The system works so far and is able to generate all of the form elements named above. Submit and reset buttons work as they're supposed to. I didn't test every layout situation for the form elements, so it might produce unexpected layout in some cases. As I said it's a proof of concept implementation and not a final product. The reason why I'm announcing this is that I will finish the project in a couple of days and I don't think I will develop the form extension any further. Maybe someone will find the sources usefull as a starting point or is even willing to develop it further. The sources and the precompiled jar archive can be found at my homepage [1]. I've also got an example fo document with my extension there, together with the resulting PDF file. So anyone who's interested can take a quick look at it. The paper I'm writing on this project will be released in couple of days (in German though, Studienarbeit) together with a little documentation on the form extension in English. Before you post on fop-user perhaps you/we should transfer it to a more 'permanent' server (since your e-mail will be in the FOP archives in perpetuity). I'm thinking that a good to place for this extension is on the 'Objects For Formatting Objects' Sourceforge project page[2] (assuming that Simon Pepping and/or other FOP committers agree). However, before we do that, we need to ensure it has the proper licensing. Please go to Apache Software Grants page for information on how to transfer[3]. I think it is a good project to be hosted by the OFFO project. The purpose of the OFFO project is to keep FO-related OS projects available for users and prospective developers. In view of the fact that you do not wish to develop it further, it should work out of the box for fop-0.20.5. Are you willing to answer questions from users? It would be good if you have some developer documentation, to give a prospective maintainer a headstart. It would be best if you release it under the Apache2 License. However, OFFO is able to host projects under any OSI approved Open Source license. You need to send the grant to me as the project maintainer; I will deposit it with the OFFO project. Note that I am not offering to do maintenance or to learn enough about the project to answer user questions. Currently OFFO does not have CVS services, but they can be set up if there is an interest. Alternatively, use Defoe. Defoe does have CVS services, and it does have the 0.25.5 maintenance branch as a module. I can give committer access to the FOP_Maint module to those like Florian, who have shown the ability and willingness to improve the code. There is a long list of developers of fixes and extensions to FOP who have been told (for how long now?) that 0.20.5 is frozen, and how many of them have applied their modifications to HEAD. Very few, I think. My intentions with Defoe, as you know, describe a completely different arc. It seems that HEAD may achieve 0.20.5 functionality in the near future, and make it to a release. In that case, it may prove useful to have a de-facto (De-foe-to) 0.20.6 functionality as a target for the first maintenance release . If Offo becomes a full-scale 0.20.5 maintenance site, with full hyphenation included, fair enough. While the Board pursues its current policy wrt licensing, e.g. with Rhino, there is no option but to home elsewhere if projects want to provide a complete service to users, so I expect to see more of it. Peter -- Peter B. West http://cv.pbw.id.au/
RE: AreaFactory patch
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Glen Mazza wrote:
Personally speaking, I am much more amenable to adding
some complexity (LM Makers, for example, or opening up
our validation) if it helps out Finn's work, because
of the sheer weight of contributions he adds to Fop.
(We slow him down, we slow down Fop.)
snip /
I'm definitely in agreement with you on this one Glen. Lets keep
Layout simple whilst its still unfinished.
Pluggable LMs can be added once we have an
initial release.
Hi fellas,
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
hinder that.
All we heard up to here is a few vague concerns about so-called increased
complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
for chrissake! It doesn't bite... or does it? Anyone?
All right, all right, maybe I'll just 'agree to disagree' in this case ;-)
--mind you, *not* WRT to Exceptions, though... I declined to further the
debate, but I'd much rather see GM read Sun's APIDoc for
java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that
FOP has no business throwing an 'IllegalArgumentException' or a
'FileNotFoundException', no matter how well the name seems to fit the
error... (esp. the first, since it subclasses RuntimeException = unchecked)
[*]
So, Tibor, can you post your patch on Bugzilla? Fine by me to leave all as
it is now... and maybe when the time is ripe, we'll use it.
Thanks very much for the contribution. I just hope this piece of sound logic
doesn't go to waste.
Greetz,
Andreas
[*] as a slightly more realistic example:
try {
...
someObject.processFile();
...
fop.run();
...
} catch( FNFE e ) {
// this will catch FNFEs regardless of which
// of the two objects it gets thrown by.
// sorting out which one here can prove to be
// quite messy and painful...
// now, if only one of the two was 'behaving'...
}
Re: AreaFactory patch
Andreas L. Delmelle wrote: All right, all right, maybe I'll just 'agree to disagree' in this case ;-) --mind you, *not* WRT to Exceptions, though... I declined to further the debate, but I'd much rather see GM read Sun's APIDoc for java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that FOP has no business throwing an 'IllegalArgumentException' or a 'FileNotFoundException', no matter how well the name seems to fit the error... (esp. the first, since it subclasses RuntimeException = unchecked) [*] On the topic of exceptions, and now that it's all over... I was puzzled by this discussion. Would anyone expect that Defoe would subclass SAXException for document validation errors? If not (it doesn't), why not? And if someone was inclined to write an FO processor using a DOM front-end, would you expect validation errors to throw subclasses of SAXException? The same fo file, with the same errors, could be processed by three different processors, using three different parsing methodologies, and the same validation errors would encountered. (OK, you can classify at least two categories of validation error, but I think the argument still applies.) SAX != XML parsing, let alone document validation. Peter
Exceptions. (Was: AreaFactory patch)
[Peter] On the topic of exceptions, and now that it's all over... I was puzzled by this discussion. Would anyone expect that Defoe would subclass SAXException for document validation errors? That is your choice. Surely exceptions that occured during SAX event handling (eg startElement) should be handled, either by wrapping the exception in a SAXException, or by passing SAXExeption subclasses along or by throwing some kind of RuntimeException (did I miss another option?). I don't think exception handling by e.printStackTrace(); is a long term solution. If not (it doesn't), why not? AFAIK, there is no well defined API to XSL:FO parsing, so everybody will do it differently. And if someone was inclined to write an FO processor using a DOM front-end, would you expect validation errors to throw subclasses of SAXException? Ofcourse not. The same fo file, with the same errors, could be processed by three different processors, using three different parsing methodologies, and the same validation errors would encountered. 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. (OK, you can classify at least two categories of validation error, but I think the argument still applies.) SAX != XML parsing, let alone document validation. True, but FOP heavily depends on SAX. regards, finn
Re: AreaFactory patch
[Chris]
I'm definitely in agreement with you on this one Glen. Lets keep
Layout simple whilst its still unfinished.
Pluggable LMs can be added once we have an
initial release.
[Andreas]
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
hinder that.
I got some minor suggestions to the patch:
- It should be strict typed: createBlock(..), createInline(..)
- It should be complete so that all area creation was done through the
factory, not just the 3 areas that Tibor needs.
All we heard up to here is a few vague concerns about so-called increased
complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
for chrissake! It doesn't bite... or does it? Anyone?
I've never bought the increased complexity argument. Not in this case
and not in any of the previous cases where it was raised.
regards,
finn
