[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 11 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-28102004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-28102004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-28102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-28102004.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-28102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-28102004.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-28102004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-28102004.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: Exception hierarchy.
[Glen] I'm not clear why you didn't derive ValidationException from SAXParseException. I know the locator is already present in FOPException, but absent the subclass from SAXParseException, it ends up being a different Locator object, i.e., user code that would handle a SAXParseException can't handle this FOPException. Perhaps just a nitpick, but I see a long-term advantage in having our ValidationExceptions subclass SAXParseException if possible. Sometime when a PropertyException is thrown (f.ex during evaludation of a relative numeric) the name of the property and the location is not available. In the patch I've added a catch in PropertyParser which add the property name and location information to the PropertyException and rethrows the augmented exception. SAXParseException keeps the location information private so it is not possible to change the location info after a SAXParseException is thrown. Other than that, the hierarchy could also have been rooted in SAXParseException. (Namely, if an embedded user of FOP wished to report both parsing and validation errors to the user in the same manner--a plausible scenario--it would be convenient to have ValidationException subclass SAXParseException.) ValidationException and SAXParseException both have SAXException as a parent, so a user can catch SAXException to deal with the different exception in a uniform manner. regards, finn
DO NOT REPLY [Bug 31899] - [PATCH] Exception hierarchy.
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=31899. 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=31899 [PATCH] Exception hierarchy. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 10:03 --- Patch applied. Additional discussions: http://marc.theaimsgroup.com/?t=10988148922r=1w=2
Re: Exception hierarchy.
I see. Thanks for the explanation. Glen --- Finn Bock [EMAIL PROTECTED] wrote: [Glen] I'm not clear why you didn't derive ValidationException from SAXParseException. I know the locator is already present in FOPException, but absent the subclass from SAXParseException, it ends up being a different Locator object, i.e., user code that would handle a SAXParseException can't handle this FOPException. Perhaps just a nitpick, but I see a long-term advantage in having our ValidationExceptions subclass SAXParseException if possible. Sometime when a PropertyException is thrown (f.ex during evaludation of a relative numeric) the name of the property and the location is not available. In the patch I've added a catch in PropertyParser which add the property name and location information to the PropertyException and rethrows the augmented exception. SAXParseException keeps the location information private so it is not possible to change the location info after a SAXParseException is thrown. Other than that, the hierarchy could also have been rooted in SAXParseException. (Namely, if an embedded user of FOP wished to report both parsing and validation errors to the user in the same manner--a plausible scenario--it would be convenient to have ValidationException subclass SAXParseException.) ValidationException and SAXParseException both have SAXException as a parent, so a user can catch SAXException to deal with the different exception in a uniform manner. regards, finn
DO NOT REPLY [Bug 31936] New: - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt Summary: [PATCH] Fonts are rendered differently between pdf and awt Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: Minor Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The userconfig.xml contains a fonts tag enabling custom fonts to be used in rendering. The awt and pdf output render these fonts differently. A way to render such fo documents more consistantly across different outputs is to enable configuration roles for the fonts xml tag.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:03 --- Created an attachment (id=13246) Describes the source changes to enable roles to be defined in the userconfig.xml
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:21 --- Created an attachment (id=13248) A simple fo document to replicate the error with.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:23 --- Created an attachment (id=13249) Fop configuration xml file
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:28 --- Created an attachment (id=13250) An executable batch file to show the difference between pdf and awt outputs
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:30 --- Created an attachment (id=13251) Example fop config xml that works with the patched files.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 15:55 --- Hi Peter: What you propose here is interesting, but I am a bit confused. You have split the font configuration into two parts, one for awt and one for pdf, and I see a few differences between them, but I don't understand what these differences are accomplishing. Would you please elaborate a bit on *why* this change solved your problem? My current theory is that any improvement that you have in making awt comparable to pdf is probably due to unintentionally getting the awt renderer to use the free-standing fonts instead of the system fonts (see below) or maybe vice versa. Also, the issue is somewhat bigger than awt vs. pdf, although that can be solved by adding some more roles. The real issue is system fonts (those registered with the o/s), which awt uses, vs. what I call free-standing fonts (those using an independent registration system), which pdf and PostScript use. System fonts don't use or need most of the stuff in the font configuration. The fonts used by the two systems can be different, and even if the fonts are identical, the metrics are obtained differently between the two systems. I have spent much of the past six months refactoring and improving the FOP font system, and I have partly addressed the issue that you mention, by adding a system-font element in the font configuration file. It doesn't do much ATM except recognize that there is a difference. See the notes here: (http://www.foray.org/release.html). If you will elaborate a bit on what you would like to see happen, I am interested. Victor Mote
[DOC] font-variant
Hi Clay: I was looking at the compliance page on a totally unrelated topic, and noticed that the property font-variant (Sec. 7.8.8) is listed as no. When it is convenient, that should probably be changed to partial with comments similar to the following: 1. True small-caps (glyph substitution) is not supported. However, faux small-caps is supported, i.e. lower-case glyphs are shown as their corresponding upper-case glyphs, but at a smaller point size. 2. [Workaround] For fonts that have true small-caps in a separate font, true small-caps can be achieved through your stylesheet. Use a different strongfont-family/strong to point to the true small-caps font instead of using strongfont-variant/strong. It may also be worth announcing the doc change on fop-user. Let me know if you have any questions. Thanks. Victor Mote
Re: Defoe
I'd meant to comment on this before, but was hoping for a little discussion from other FOP committers. Perhaps I was waiting until the body got even 'colder'... Speaking for myself, I want to be clear that I (and I assume others) feel very fortunate to have had the benefit of the work of Peter B. West on the alt.design portion of FOP. With the possibility of Peter moving on to work with Defoe, I just wanted to thank you personally, Peter, for your hard work and always welcome (IMHO) contributions. Glen's lead off below (jokingly 'not waiting until the body is cold...' as it were) is probably an appropriate course of action to take (although I would've tried to find a way to sugar-coat it ;-)). But I want to be clear, that (at least in my eyes) Peter (and for that matter Victor and other inactive committers) are welcome--nay encouraged--to comment and contribute to FOP development now and in the future. Web Maestro Clay On Oct 23, 2004, at 12:11 PM, Glen Mazza wrote: Best of luck with Defoe! And, ummm, if you could pardon me for not waiting until the body is cold (Well OK...98.3...98.1...97.9--there! Practically an ice cube now... ;), I think we should have the Alt-Design tab moved off the FOP website and on to Defoe's, and place a link instead on our resources page to Defoe. This would help reduce the size of our website and make it easier to modify/maintain, but perhaps more importantly, give visitors to FOP the indication that we're better settled on the architecture of our next release. Glen --- Peter B. West [EMAIL PROTECTED] wrote: alt-design should probably be noted as a dormant branch, and me as an inactive committer. Peter 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: [DOC] font-variant
Victor, On Oct 28, 2004, at 12:52 PM, Victor Mote wrote: Hi Clay: I was looking at the compliance page on a totally unrelated topic, and noticed that the property font-variant (Sec. 7.8.8) is listed as no. When it is convenient, that should probably be changed to partial with comments similar to the following: Funny you should pipe in today. Believe it or not, last night, /forrest/ actually returned a BUILD SUCCESSFUL using the current xml-fop/ (after many weeks/months? spent tweaking this and that)! More details (including pretty links to the forthcoming xml-fop web site) can be found in the ongoing Forrest thread[1] (or, now that I figured out how to use my apache.org/~clay/ web space, you could just go here[2] :-p). Unfortunately, I still have a few problems (see [1]), including a rather gaping hole in the FOP Compliance page (it doesn't show *any* content--d'oh!). I'm also working on some problems with various problems in the alt.design portion of the web site. The problems are most notably: - design/alt.design/xml-parsing.html (no content) - design/alt.design/properties/introduction.html (content but all sub-links have no content) 1. True small-caps (glyph substitution) is not supported. However, faux small-caps is supported, i.e. lower-case glyphs are shown as their corresponding upper-case glyphs, but at a smaller point size. 2. [Workaround] For fonts that have true small-caps in a separate font, true small-caps can be achieved through your stylesheet. Use a different strongfont-family/strong to point to the true small-caps font instead of using strongfont-variant/strong. It may also be worth announcing the doc change on fop-user. Let me know if you have any questions. Thanks. Actually, if you could help me a bit to figure out what happened with the compliance page, that might help me understand more about that page, and the system used to output its rather complicated table. Thanks! Victor Mote [1] http://issues.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=14876 [2] http://www.apache.org/~clay/xml-fop/ 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: Defoe
Clay, Thanks for the comments. I would be interested to see the alt-design doco running under the new Forrest regime before it is removed, because I would like to take advantage of your hard work in coming to terms with Forrest. It was difficult to get the documentation working in the original Forrest-based version, and I would like to see if, and how, it can be done in a newer Forrest. Peter
Re: [DOC] font-variant
Clay Leeds wrote: Unfortunately, I still have a few problems (see [1]), including a rather gaping hole in the FOP Compliance page (it doesn't show *any* content--d'oh!). I'm also working on some problems with various problems in the alt.design portion of the web site. The problems are most notably: - design/alt.design/xml-parsing.html (no content) - design/alt.design/properties/introduction.html (content but all sub-links have no content) Ah, were you perhaps hoping to eliminate these problems? It might, nonetheless, prove useful to solve them. FOP's documentation may use such methods in future. Peter
Re: Defoe
I'd be happy to help out! Of course, since it appears to be moving anyway, it might be easier for me to move your documentation to a new forrest install and go from there. Either way, I'm happy to do what I can. (IOW pile it on! :-p) Web Maestro Clay On Oct 28, 2004, at 2:00 PM, Peter B. West wrote Clay, Thanks for the comments. I would be interested to see the alt-design doco running under the new Forrest regime before it is removed, because I would like to take advantage of your hard work in coming to terms with Forrest. It was difficult to get the documentation working in the original Forrest-based version, and I would like to see if, and how, it can be done in a newer Forrest. Peter 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: [DOC] font-variant
Clay Leeds wrote: Unfortunately, I still have a few problems (see [1]), including a rather gaping hole in the FOP Compliance page (it doesn't show *any* content--d'oh!). I'm also working on some ... Actually, if you could help me a bit to figure out what happened with the compliance page, that might help me understand more about that page, and the system used to output its rather complicated table. First, I hope my comment wasn't considered a nag. I just wanted to pop that documentation change off of my stack. Second, the new web site is smokin' hot. OK. The compliance page uses a different DTD than any of the other pages: xml-fop/src/documentation/resources/schema/dtd/compliance-v10.dtd One possibility to consider is changing it to the standard format. That is probably possible, but you may have to give some things up to get it done. My recollection is that I always decided it was worth it to use the non-standard way. Also, the standard DTD may be better now than it was. A different DTD means that it must use a different stylesheet also. This is likely the crux of the problem. The process of telling Forrest/Cocoon about the compliance stylesheet is probably broken. The easiest solution is probably to ask on the Forrest user list. They were always extremely helpful in solving these problems. When I was working with Forrest, it required a decent understanding of Cocoon, but their newer versions might hide some of that. Look in one of the sitemap files (sorry -- I don't remember which one is the current one): xml-fop/src/documentation In each you'll see a section entitled FOP Additions (line 295 in sitemap.xmap, and line 257 in sitemap-0.5.xmap). That shows you the location of the stylesheets as well (there is another entry later for the to-pdf stylesheet). Find out where the equivalent sitemap for the new version is and how to mimic the logic that is here. That's about all I can think of to tell you. Good luck. Victor Mote
Re: Defoe
Thanks Clay. Please disregard deeply unworthy comment on a previous message. Peter Clay Leeds wrote: I'd be happy to help out! Of course, since it appears to be moving anyway, it might be easier for me to move your documentation to a new forrest install and go from there. Either way, I'm happy to do what I can. (IOW pile it on! :-p)
Re: [DOC] font-variant
On Oct 28, 2004, at 2:43 PM, Victor Mote wrote: Clay Leeds wrote: Unfortunately, I still have a few problems (see [1]), including a rather gaping hole in the FOP Compliance page (it doesn't show *any* content--d'oh!). I'm also working on some ... Actually, if you could help me a bit to figure out what happened with the compliance page, that might help me understand more about that page, and the system used to output its rather complicated table. First, I hope my comment wasn't considered a nag. I just wanted to pop that documentation change off of my stack. Not taken as such... the thought didn't even cross my mind! Second, the new web site is smokin' hot. Thanks! Perhaps we might even get this live before xmlgraphics domain goes live... OK. The compliance page uses a different DTD than any of the other pages: xml-fop/src/documentation/resources/schema/dtd/compliance-v10.dtd I saw that... [OT] Interestingly enough, the BUILD process would halt at compliance.html if I didn't have net-access and as luck would have it, when I was making this break through, my neighborhood lost power due to the Alaskan storm. hmph! One possibility to consider is changing it to the standard format. That is probably possible, but you may have to give some things up to get it done. My recollection is that I always decided it was worth it to use the non-standard way. Also, the standard DTD may be better now than it was. I'll see if I can find out more information about it on the Forrest side of things... A different DTD means that it must use a different stylesheet also. This is likely the crux of the problem. The process of telling Forrest/Cocoon about the compliance stylesheet is probably broken. The easiest solution is probably to ask on the Forrest user list. They were always extremely helpful in solving these problems. When I was working with Forrest, it required a decent understanding of Cocoon, but their newer versions might hide some of that. Look in one of the sitemap files (sorry -- I don't remember which one is the current one): xml-fop/src/documentation sorry... that one is pretty much gone. Although it's still in CVS, it must be removed in order for me to get a BUILD SUCCESSFUL. However, I might have to add a 'mini' sitemap.xmap to handle just this one item (and perhaps the other alt.design 'problems' as well). In each you'll see a section entitled FOP Additions (line 295 in sitemap.xmap, and line 257 in sitemap-0.5.xmap). That shows you the location of the stylesheets as well (there is another entry later for the to-pdf stylesheet). Find out where the equivalent sitemap for the new version is and how to mimic the logic that is here. That's about all I can think of to tell you. Good luck. Victor Mote Thanks! This is just the discussion I was hoping for! Serendipitous! Glad you 'pestered' me! ;-p 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: Defoe
--- Clay Leeds [EMAIL PROTECTED] wrote: Speaking for myself, I want to be clear that I (and I assume others) feel very fortunate to have had the benefit of the work of Peter B. West on the alt.design portion of FOP. With the possibility of Peter moving on to work with Defoe, I just wanted to thank you personally, Peter, for your hard work and always welcome (IMHO) contributions. Me too. Remember, I nominated and voted for Peter West for XML Graphics chair. I thought he would have represented XML Graphics quite well. I do want to reduce the number of pages on our website though--making it smaller will facilitate getting it translated into Japanese. (Tokyo-based AntennaHouse already has an extensive Japanese language site.) It's too early now, but I'm looking forward to a translated site of our own. Glen
Re: Defoe
On Oct 28, 2004, at 3:21 PM, Glen Mazza wrote: --- Clay Leeds [EMAIL PROTECTED] wrote: Speaking for myself, I want to be clear that I (and I assume others) feel very fortunate to have had the benefit of the work of Peter B. West on the alt.design portion of FOP. With the possibility of Peter moving on to work with Defoe, I just wanted to thank you personally, Peter, for your hard work and always welcome (IMHO) contributions. Me too. Remember, I nominated and voted for Peter West for XML Graphics chair. I thought he would have represented XML Graphics quite well. I forgot about that. Thanks for reminding me! :-D I do want to reduce the number of pages on our website though--making it smaller will facilitate getting it translated into Japanese. (Tokyo-based AntennaHouse already has an extensive Japanese language site.) It's too early now, but I'm looking forward to a translated site of our own. Glen I'm looking forward to that release! The more languages we have, the more users we can get (and perhaps, the more code-heavy java developers we can get! w00t!) 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: Defoe
Peter: I too wish you the best of luck with Defoe and with whatever your future FOP involvement may be. One of my motivations with the modularization work was to make room for the competing ideas, mostly yours, to share what could be shared. This may help explain my frustration at your opposition to it (I didn't catch on until too late that your deal was all-or-nothing). At any rate, I wish to make it clear that I have high personal regard for you, and I consider it an honor and privilege to have worked with you. I thought of you a few days ago as I was building (again) a little event system for the FOTree system (in FOray this time). When I built it in FOP head over a year ago, it threw events for end-of-pageSequence and end-of-Document. When I built it on FOray a few days ago, I added an event for end-of-FObj. That way a really eager layout system like yours can grab it and go if it wants to. Its not exactly pull parsing, but it seems like a guy could build his queue from that and do whatever he wants to. That is the theory anyway. It took just a few minutes to implement. I am knee-deep in modularization (again), and although it will be a while before I get there, I am eager to either prove or disprove my theory about using an interface for the grafting of reference areas. I'll try to keep you posted through fop-dev as (or if) I make any progress. I certainly wish you great success with Defoe. Barring all of us working together with one mind (which has I think been well-enough tested), what could be better than to have multiple successful open-source implementations? Victor Mote
Re: Defoe
Victor, Thank you for the compliments. It's interesting to see the development of a multiple approaches, and the strength with which differing views are held. I've started a blog as a diary of Defoe development and, at the moment, my learning experiences with Java 5.0, especially Typesafe Enums and Generics. If you drop in there from time to time, you can see what I am up to. Have you considered one for FOray? Peter Victor Mote wrote: Peter: I too wish you the best of luck with Defoe and with whatever your future FOP involvement may be. One of my motivations with the modularization work was to make room for the competing ideas, mostly yours, to share what could be shared. This may help explain my frustration at your opposition to it (I didn't catch on until too late that your deal was all-or-nothing). At any rate, I wish to make it clear that I have high personal regard for you, and I consider it an honor and privilege to have worked with you. I thought of you a few days ago as I was building (again) a little event system for the FOTree system (in FOray this time). When I built it in FOP head over a year ago, it threw events for end-of-pageSequence and end-of-Document. When I built it on FOray a few days ago, I added an event for end-of-FObj. That way a really eager layout system like yours can grab it and go if it wants to. Its not exactly pull parsing, but it seems like a guy could build his queue from that and do whatever he wants to. That is the theory anyway. It took just a few minutes to implement. I am knee-deep in modularization (again), and although it will be a while before I get there, I am eager to either prove or disprove my theory about using an interface for the grafting of reference areas. I'll try to keep you posted through fop-dev as (or if) I make any progress. I certainly wish you great success with Defoe. Barring all of us working together with one mind (which has I think been well-enough tested), what could be better than to have multiple successful open-source implementations?
