[VOTE:RESULTS] Project resolution for XML Graphics
Time is over. Let's see the results (I hope I've got everything right here): PART A -- 9 +1s, no -1s FOP team: Glen Mazza, Peter B. West, Clay Leeds, Christian Geisert, Jörg Pietschmann, Chris Bowditch, Simon Pepping, Jeremias Märki Batik: Thomas DeWeese I think we can consider the vote on the revised resolution proposal passed. Remember, we'll always be able to add additional PMC members later on. PART B -- This is the initial XML Graphics PMC (sorted by lastname): - Chris Bowditch - Thomas DeWeese - Christian Geisert - Clay Leeds - Jeremias Märki - Glen Mazza - Simon Pepping - Jörg Pietschmann - Peter B. West PART C -- We've had two distinct nominations: - Peter B. West - Jeremias Märki I'll follow up with a vote for the chair shortly. Archive link: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=814863 Thanks to everyone participating. Jeremias Maerki
[VOTE] PMC chair for XML Graphics
So let's vote on the PMC chair for the XML Graphics project. We have two nominated candidates: [ ] I vote for Peter B. West as PMC chair. [ ] I vote for Jeremias Maerki as PMC chair. Simple majority will decide. If we get a draw we'll figure something out. This vote will close at 23:59 GMT, Thursday July 13, 2004: http://www.timeanddate.com/counters/customcounter.html?day=13month=7year=2004hour=23min=59 Jeremias Maerki
Re: [VOTE] PMC chair for XML Graphics
Jeremias Maerki wrote: So let's vote on the PMC chair for the XML Graphics project. We have two nominated candidates: [ ] I vote for Peter B. West as PMC chair. [ ] I vote for Jeremias Maerki as PMC chair. Simple majority will decide. If we get a draw we'll figure something out. I'm abstaining, in case anyone is confused by the above. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
DO NOT REPLY [Bug 30006] New: - eps doesn't show up in recent GhostScript versions
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=30006. 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=30006 eps doesn't show up in recent GhostScript versions Summary: eps doesn't show up in recent GhostScript versions Product: Fop Version: 0.20.5 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems that when rendering a PDF with an eps embedded in it, it won't show up in a GhostScript viewer/renderer with version higher than 8.x. However using GhostScript 7.06 the eps does show up. And by showing up I mean transforming the PDF to PS (and optionally back to PDF using GhostScript or Acrobat Distiller). This is the known trick of PDFs with eps's that don't show up, but after the transform trick, they do. I've tested this on a windows2000 professional machine, using fop 0.20.5 and GhostScript. The GNU GhostScript 7.06 works for me (http://sourceforge.net/project/showfiles.php?group_id=1897package_id=22075) and GhostScript 8.14 doesn't (http://sourceforge.net/project/showfiles.php?group_id=1897package_id=1845)
Re: Javasrc, JXR and documentation
On Jul 8, 2004, at 5:02 PM, Peter B. West wrote: Clay Leeds wrote: Peter, Did you get a chance to try the procedure Nicola recommended[1]? I haven't gotten a successful build yet, but I'm still working at it. When I do, I'll try to do as he suggested. No, I've been too busy working on the FAD layout lately. I can relate. Of course, there's also the 'issue' of you being a newlywed! Tell the Mrs. the 'guys' say 'Cheers!' :-) I actually was getting stuck on the BUILD portions, but I was still using forrest 0.5.1. Much of the forrest development is going towards 0.6 which I believe has an imminent release (days? weeks? months? :-D). With all of the stuff going on (XML Graphics, forrest.apache.org, etc.) coupled with the fact that the forrest-site 'skin' is a bit outdated, I thought it best to work toward a 0.6 version of the FOP website. At the same time I'll also change to one of the other skins (css-style, xhtml-css, krysalis-site, tigris-site, etc.). If anyone has a particular preference, please chime in! I'm leaning a bit toward the css-style, as it appears to offer the greatest flexibility, and seems to better leverage css over tables... But we'll see! As we're all anxious to see a Whole Site PDF (not to mention the 'new' logo :-D) I might use one of the others if css-style isn't ready in time. BTW, how does Simon's recent Documentation[2] figure in to this? I don't know. I think the fact that Simon's docs are Docbook based will militate against linking in to the sources, but Simon would be in the best position to answer this. If it could be done, it would be a great boon to the documentation. That actually shouldn't be too hard... It appears that forrest is pretty much built to work with docbook[3]. We can either just 'stick it in the directory' and It Should Just Work(tm)--albeit with limited transformation of the presumably more advanced DocBook elements, or we can use the full DocBook stylesheets themselves (which is probably the preferred method). Each has its own issues. [OT] militate? heh... there's a word I tend to 'try' to stay away from in every day conversation... (it's not that hard, as I don't think I've ever heard it...). [1] http://marc.theaimsgroup.com/?l=fop-devm=108680587917268w=2 [2] http://marc.theaimsgroup.com/?l=fop-devm=108844739724995w=2 [3] http://forrest.apache.org/faq.html#docbook Web Maestro Clay
Re: [VOTE] PMC chair for XML Graphics
Jeremias Maerki wrote: [ ] I vote for Peter B. West as PMC chair. [X] I vote for Jeremias Maerki as PMC chair. J.Pietschmann
Re: adding fonts to fop applet
--- Simon Pepping [EMAIL PROTECTED] wrote: - From an app: add a configuration object to the FOUseragent object, Why do you need to drag in the Avalon library for this? For the classes in question, Avalon is just providing a very thin wrapper--can't we do this directly against the JDK? Glen
Re: adding fonts to fop applet
--- Simon Pepping [EMAIL PROTECTED] wrote: Well, was, I hope. I have just committed code which enables using a user configuration file and adding fonts from it. Thanks, Simon. Its good that we have people of your skill on our team. Glen
[PROPOSAL] API Changes
Team, There are two possible API changes I am wondering if we should make. I'm thinking about longer-term market share of our 1.0 product, even if things get rocky for us for a few months. Simon's changes are making the HEAD code in FOP close to being useful, and so we may have a narrowing window of opportunity in getting the right API for us for 1.0. Two ideas, I'm not 100% sure on either but they seem to me to be potentially good for us: 1.) Drop the apps.Driver class and incorporate its remaining code into apps.Fop. Reason: Fop appears to be a better self-documenting class name within user's embedded code. It's also a neat name for a product. User's code would move from looking like this: // Construct driver Driver driver = new Driver(); // Setup Renderer driver.setRenderer(Driver.RENDER_PDF); Result res = new SAXResult(driver. getContentHandler()); To this: // Construct FOP instance Fop fop = new Fop(); // Setup Renderer fop.setRenderer(Fop.RENDER_PDF); Result res = new SAXResult(fop. getContentHandler()); Does the lower look better--over the long term, will it make FOP more well known, more used? Note: Backward compatibility headaches will be there but perhaps less of an issue, due to the changed logger (i.e., user code may have to change anyway). And we have some precedence: the Struts team, in the 1.1 release, did not make it backwards compatible with 1.0.2, and appears none the worse with its user base because of it. And by having a much more solid API in 1.1 (compared to trying to juggle two APIs), is probably grabbed many more new users as well. Also, in the year I've been on FOP, the Driver class has fallen from about 780 to 400 lines of code, so it wouldn't be that overwhelming to the apps.Fop class. 2.) Shall we roll the dice? I wonder if we should go 100% JAXP for 1.0, i.e. coding just like this [1] for SAXSources and [2] for DOMSources, and removing the older methods from Driver where one would be using XSLTInputHandler. We're currently that way with [2] (As of yesterday ;), the question is should we go that way with [1] now? [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleXML2PDF.java?rev=HEAD [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?rev=HEAD By keeping everyone coding the same way this will keep our user lists very clear, streamlined and useful for everyone. It is very good for our user base to be on JAXP--good for them, for FOP, and the Java community. Also, Driver can be very nicely simplified were some of these render() functions removed in favor of getContentHandler(). FYI, for about 18 months now Jeremias' examples on the embedding page have been JAXP-only, and we removed just about every reference on the embed page to XSLTInputHandler about a year ago. (Note: I'm not recommending the removal of XSLTInputHandler, it is still very much in use in our code, and does a good job. Just recommending the removal of functions from Driver that would cause one to want to use it externally.) Sorry for the long post. Thoughts? Thanks, Glen
Re: [PROPOSAL] API Changes
Glen Mazza wrote: Team, ... 1.) Drop the apps.Driver class and incorporate its remaining code into apps.Fop. Reason: Fop appears to be a better self-documenting class name within user's embedded code. It's also a neat name for a product. User's code would move from looking like this: // Construct driver Driver driver = new Driver(); // Setup Renderer driver.setRenderer(Driver.RENDER_PDF); Result res = new SAXResult(driver. getContentHandler()); To this: // Construct FOP instance Fop fop = new Fop(); // Setup Renderer fop.setRenderer(Fop.RENDER_PDF); Result res = new SAXResult(fop. getContentHandler()); Does the lower look better--over the long term, will it make FOP more well known, more used? FWIW, FAD merged Driver into Fop some time ago. From memory, the only issues were to do with the AWT renderer and its re-start capability (which I gather is not functioning anyway.) While we're at it, what about moving Fop to org.apache.fop? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
