DO NOT REPLY [Bug 29501] - creates a new pop-up
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=29501. 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=29501 creates a new pop-up [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-06-11 07:47 --- I dont understand what makes you think this is a bug in FOP? The problem appears to be in your servlet environment. FOP knows nothing about servlets or web servers it merely generates a PDF from XSL-FO upon request. You are going to have to provide more evidence/explanations if you want to convince me this is a bug with FOP.
DO NOT REPLY [Bug 29486] - Consolidate page generation code into FOTreeHandler
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=29486. 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=29486 Consolidate page generation code into FOTreeHandler [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-11 17:21 --- Applied.
Re: Accessing File in a WAR for XSLTInputHandler
For archival reasons, please ask these questions on the FOP User list. The same developers are on both. Glen --- [EMAIL PROTECTED] wrote: - My application is deployed in a WAR format on Unix. The XSLTInputHandler is trying to access the XSL and the XML files on the system but the getRealPath() and the getResource() methods return null /or a path which included the war info and the XSLTInputHandler errors out with FileNotFoundException. The XSLTInputHandler constructor with InputSource and String doesnt work ( its a bug and I dont see it being fixed as per bugzilla). So my question is how do i get the File objects for XSL and XML from a WARred setup? Thanks
Re: CVS vulnerabilities?
Thanks for the link--I didn't know about this. Still, switching to SVN would probably aggravate the problem, by draining users and developers away from CVS--hence slowing CVS' bug fixes and greater security enhancements. There's nothing magical about SVN--it is open source too and subject to the same time constraints and developer limitations of any other project. However, by dividing open source resources across two version control projects, the economy of scale is lost, and I'm concerned we will end up with two mediocre open-source version control systems instead. Glen --- Clay Leeds [EMAIL PROTECTED] wrote: I don't know who this should go to (they probably already know), but according to Reuters[1], the CVS system has some fairly significant holes. I know Forrest moved to SVN not too long ago. Have we thought of doing it ourselves? Web Maestro Clay [1] http://news.com.com/More+flaws+foul+security+of+open-source+repository/ 2100-7344_3-5229750.html?tag=macintouch
Re: CVS vulnerabilities?
On Jun 11, 2004, at 10:35 AM, Glen Mazza wrote: Thanks for the link--I didn't know about this. Still, switching to SVN would probably aggravate the problem, by draining users and developers away from CVS--hence slowing CVS' bug fixes and greater security enhancements. There's nothing magical about SVN--it is open source too and subject to the same time constraints and developer limitations of any other project. However, by dividing open source resources across two version control projects, the economy of scale is lost, and I'm concerned we will end up with two mediocre open-source version control systems instead. Glen Point well-taken about diluting the pool of OSS projects and available developers... My point in bringing this up was more to put the alert out there, and also to note that other projects @apache.org (most notably forrest) have moved to SVN. Being a relative newbie to CVS, it doesn't make much difference to me which one we use, although I definitely like the idea of supporting one system and sticking to it. Web Maestro Clay --- Clay Leeds [EMAIL PROTECTED] wrote: I don't know who this should go to (they probably already know), but according to Reuters[1], the CVS system has some fairly significant holes. I know Forrest moved to SVN not too long ago. Have we thought of doing it ourselves? Web Maestro Clay [1] http://news.com.com/More+flaws+foul+security+of+open-source+repository/ 2100-7344_3-5229750.html?tag=macintouch
FOP Forrestbot questions
I made my 1st CVS *commit* via SSH last night--team.xml--as a test (the de facto initiation? ;-)), but don't recall how to push it LIVE (thought it would be LIVE this a.m. w the 6-hour Forrestbot 'refresh'). I hesitate to do use the Forrestbot Web Interface 'til I'm clearer about its use. Also, the temp version of team.html[2] shows the dreaded breadcrumb.js error. Can someone clue me in on when to use Forrestbot 'publish' as opposed to allowing the auto Forrestbot 'refresh'? [1] http://forrestbot.cocoondev.org/sites/xml-fop/team.html
Re: FOP Forrestbot questions
I think you *have* to use publish--(IIRC auto refreshing will work only for what you *manually* place in CVS xml-site CVS) Don't worry, go ahead and press the publish button--the Forrestbot web interface is a lot more robust than it looks! After publishing, you will need to wait up to 6 hours before the site moves to production. (It updates after a publish 4 times per day IIRC.) Also, anytime after publishing, go ahead and update the xml-site CVS with the previous breadcrumb.js file. You have karma on xml-site also. [BTW, you forgot to add Jeremy's birthyear to your bio--no big deal, but you might be getting congratulatory emails/demands for cigars every late June! ;)] Glen --- Clay Leeds [EMAIL PROTECTED] wrote: I made my 1st CVS *commit* via SSH last night--team.xml--as a test (the de facto initiation? ;-)), but don't recall how to push it LIVE (thought it would be LIVE this a.m. w the 6-hour Forrestbot 'refresh'). I hesitate to do use the Forrestbot Web Interface 'til I'm clearer about its use. Also, the temp version of team.html[2] shows the dreaded breadcrumb.js error. Can someone clue me in on when to use Forrestbot 'publish' as opposed to allowing the auto Forrestbot 'refresh'? [1] http://forrestbot.cocoondev.org/sites/xml-fop/team.html
[Fwd: CVS and Subversion]
Original Message Subject: CVS and Subversion Date: Fri, 11 Jun 2004 12:17:27 +0200 From: Dirk-Willem van Gulik [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: Apache Infrastructure [EMAIL PROTECTED] In reaction to some worried emails related to some projects moving from CVS to Subversion. - Do not panic. - There is no ASF driven push (yet) for this move, no deadlines, no forcing. - It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. - But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: FOP Forrestbot questions
On Jun 11, 2004, at 1:02 PM, Glen Mazza wrote: I think you *have* to use publish--(IIRC auto refreshing will work only for what you *manually* place in CVS xml-site CVS) Don't worry, go ahead and press the publish button--the Forrestbot web interface is a lot more robust than it looks! That's what 'scares' me! Anyway, i tried logging in got the error, then remembered the login pw for it. Being the chief nitpicker has its advantages! :-p Doing a 'refresh' (to pick up Jeremy's birth-year) which will be followed by a publish as soon as its confirmed... After publishing, you will need to wait up to 6 hours before the site moves to production. (It updates after a publish 4 times per day IIRC.) Also, anytime after publishing, go ahead and update the xml-site CVS with the previous breadcrumb.js file. You have karma on xml-site also. Just to ensure I've got the right command, assuming the newest (munged) version of breadcrumbs.js is 1.13, I would use the following command command to revert: cvs update -j 1.13 -j 1.12 breadcrumbs.js I just checked, and it still shows the revision line as: /* $Id: breadcrumbs.js,v 1.12 2004/04/11 22:33:01 gmazza Exp $ */ Therefore I'm assuming that when Forrestbot munges the file it will update to revision 1.13 2004/06/11 (I'll check first!)... Unfortunately, since it looks OK now, we'll have to wait 'til *after* we see it LIVE. [BTW, you forgot to add Jeremy's birthyear to your bio--no big deal, but you might be getting congratulatory emails/demands for cigars every late June! ;)] Glen As long as they're of the chewing gum variety, bring 'em on! I don't smoke! Blech! BTW, I appended the year to it (don't know if it made it into the Forrestbot 'publish' but it should've!)... --- Clay Leeds [EMAIL PROTECTED] wrote: I made my 1st CVS *commit* via SSH last night--team.xml--as a test (the de facto initiation? ;-)), but don't recall how to push it LIVE (thought it would be LIVE this a.m. w the 6-hour Forrestbot 'refresh'). I hesitate to do use the Forrestbot Web Interface 'til I'm clearer about its use. Also, the temp version of team.html[2] shows the dreaded breadcrumb.js error. Can someone clue me in on when to use Forrestbot 'publish' as opposed to allowing the auto Forrestbot 'refresh'? [1] http://forrestbot.cocoondev.org/sites/xml-fop/team.html Web Maestro Clay - [EMAIL PROTECTED] -- Web Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: [Fwd: CVS and Subversion]
A very interesting read! Looks like a really nice tool. We may consider it ourselves in-house, as the infrastructure has some really nice features! Thanks for the heads up! Web Maestro Clay On Jun 11, 2004, at 3:05 PM, Peter B. West wrote: Original Message Subject: CVS and Subversion Date: Fri, 11 Jun 2004 12:17:27 +0200 From: Dirk-Willem van Gulik [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: Apache Infrastructure [EMAIL PROTECTED] In reaction to some worried emails related to some projects moving from CVS to Subversion. - Do not panic. - There is no ASF driven push (yet) for this move, no deadlines, no forcing. - It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. - But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
SVG Generator
I recently asked the following question on the Java 2D Forum at Sun. quote The 1.4.2 API description for Graphics2D has: Some Graphics2D objects can be used to capture rendering operations for storage into a graphics metafile for playback on a concrete device of unknown physical resolution at a later time. Since the resolution might not be known when the rendering operations are captured, the Graphics2D Transform is set up to transform user coordinates to a virtual device space that approximates the expected resolution of the target device. Further transformations might need to be applied at playback time if the estimate is incorrect. I can find no further information about using this facility. I would like to be able to output to a virtual GraphicsDevice implementing PDF output. /quote Out of the blue, I was directed to the SVG Generator, which does for Batik what I have in mind for alt-design. Talk about serendipity! We have been discussing an integration of Batik and FOP under an XML Graphics umbrella, a discussion driven particularly by Jeremias. It has seemed to me for a while now that using the 2D API as a basis for rendering offers the possibility of a clean, or at least well documented and understood, interface between layout and rendering. In that case of alt-design, it is also the basis for manipulating the layout. I think the approach may offer benefits to HEAD. Providing a common interface between layout and rendering for PDF and PS would be beneficial for all, and would bring pluggable layout closer to realisation. The SVG renderer would virtually be in place already. Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I believe that the same approach could be used with the structure renderers. With the current approach to RTF, it seems to me that a number of sacrifices have to be made. The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
--- Peter B. West [EMAIL PROTECTED] wrote: Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I think you have that already in the render.Renderer interface--which defines those methods that a Renderer must be able to implement. Review it and let us know where you think it needs modification. The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 Glen
