JAXP missing on JDK1.3 ant build
I'm guessing this won't affect many users out there, but I have discovered that if you try to build xmlgraphics-commons using JDK1.3 there is a dependency on the JAXP classes that you get for free in J2SE1.4. These JAXP classes are provided by the xml-apis-1.3.02.jar bundle that you can easily find in fop/lib directory. So long as the project aims to be JDK1.3 backwards compatible it might be worth making this jar available to the commons/lib folder so ant will automatically pick it up when compiling. Adrian - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: KML GRAPHIC EDITOR
This is not really the correct forum for this question. But simple searching around on google gave me this link which may prove to be useful for your purposes :- http://www.northgates.ca/kmleditor/ Adrian. avendramin wrote: Good morning Comunity, I'm Italian, sorry for my english. I am trying to find a KML Graphics editor, because I want to evidence, to place in prominence, a specific region in google maps. Please help me. Anticipatamente thanks. - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adrian Cumiskey for Committer
Hi Chris, My preferred userid is acumiskey, if this is not available (due to some bizarre scenario..) then I will take ajc. I'm looking forward to being able to make further contributions in the future :). Many thanks, Adrian Cumiskey. Chris Bowditch wrote: Chris Bowditch wrote: The Vote has been running for 5 days, so it should be concluded: 8 +1s in total (7 binding), 0 +0 and 0 -1, so the vote passes. 3 PMC members did not vote. Well done Adrian! Adrian, For the next step I need a preferred userid (with some alternatives in case that preference is unavailable) A list of all Apache committers can be seen here: http://people.apache.org/~jim/committers.html You're ICLA is already on file, so no action is required there. Thanks, Chris - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going for 1.4 or 1.5 as minimum Java version?
For as long as Sun continue to support a version of Java I think that we should continue to try and support it. So I'd just drop 1.3 and go with 1.4 for now. Adrian. Chris Bowditch wrote: Jeremias Maerki wrote: No reactions so far. Interesting. Anyway, based on the user poll, my opinion is to go for Java 1.4 for the moment and reevaluate Java 1.5 next summer. I mean I'd love to use generics and java.util.concurrent but I think it is just a bit too soon to drop 1.4. I agree. I don't want Java 1.4 dropped yet because of the type of environments where FOP will typically be used, i.e. Batch Processing environments which are often old mainframes, e.g. AS/400, or other older and less popular Unix flavours. Most of these older environments simply cannot be upgraded to newer JDKs and by excluding them we are making people either stay on older releases of FOP or losing potential users. Neither scenario sits well with me, and I fail to see the real benefit that generics gives us. I can still implement new functionality without them, no? Chris - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Temporary File Storage
Hi all, I have written a set of general purpose temporary file storage classes that are used by the AFP Renderer in FOP on the Temp_AFPGOCAResources branch I am working on. I use them to temporarily store and retrieve image files and AFP data structures to disk in a memory conservative fashion. I have abstracted away all AFP specific functions into subclasses and am now thinking that these base classes would prove quite useful for some other temporary storage needs and was wondering where they might best reside. I think it should probably best go in commons-io, but it is maybe a little high level for there and would impose an additional dependency on FOP I'd also maybe need to request some karma to commit them to the project. I'm also thinking it would seem a little wrong for them to go in xmlgraphics-commons as the work has nothing to do with images/fonts or output formats. Maybe I should just place them in FOP for now? I would be interested to hear your suggestions on where you think they should live. Adrian. - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FOP 0.95
Unfortunately only had a very minimal amount of time to test, but +1 from me. Adrian. Jeremias Maerki wrote: With much too much delay I'm happy to present the final 0.95 artifacts for a release vote. The release files are built from: http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_95/ (revision 681373, on Ubuntu 8.04LTS with Sun Java 1.4.2_18) The files can be found here: http://people.apache.org/~jeremias/fop/fop-0.95/ 7af50bf58924dd22d71d22d8ad90b268 *fop-0.95-bin.tar.gz c3625c66e368e3a6ae52e1d8607e6c92 *fop-0.95-bin.zip 58593e6c86be17d7dc03c829630fd152 *fop-0.95-src.tar.gz adeb416f81125d8554a621050f319632 *fop-0.95-src.zip Please review and cast your votes (on general@). +1 from me. Thanks, Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Temporary File Storage
Hi Jeremias, Jeremias Maerki wrote: On 01.08.2008 18:42:43 Adrian Cumiskey wrote: Hi all, I have written a set of general purpose temporary file storage classes that are used by the AFP Renderer in FOP on the Temp_AFPGOCAResources branch I am working on. I use them to temporarily store and retrieve image files and AFP data structures to disk in a memory conservative fashion. I have abstracted away all AFP specific functions into subclasses and am now thinking that these base classes would prove quite useful for some other temporary storage needs and was wondering where they might best reside. I think it should probably best go in commons-io, but it is maybe a little high level for there and would impose an additional dependency on FOP How so? From my understanding, when providing a release of FOP we would need to provide a properly release versioned commons-io jar (as apposed to just svn), so there would be a dependency on commons-io being released containing the additional code prior to or at the same time as FOP. I'd also maybe need to request some karma to commit them to the project. Well, you'd need to make a proposal there before you could commit it. Karma is the second step IMO. Agreed. I'm also thinking it would seem a little wrong for them to go in xmlgraphics-commons as the work has nothing to do with images/fonts or output formats. So why did you commit it anyway? Without giving everyone a chance to react first? Yes I could have left it a little longer but I hadn't received any responses back, so I assumed (wrongly) that most people didn't have a strong opinion on the matter. I wanted to resolve this decision swiftly so I would be able to crack on with the branch work. Now that you have raised an objection I will of course simply place it in my FOP branch for now and we can worry about where it should go later. So far, I've only moved stuff to XGC which was clearly destined to be shared between Batik and FOP or which was dependent on those shared components. I think FileStore and its associated classes could prove quite useful for other components which wish to save memory by temporarily saving data to file and then retrieving later. Maybe I should just place them in FOP for now? I would be interested to hear your suggestions on where you think they should live. IMO, FOP is the right place for now. Probably even under the AFP package. ATM, I can't see too much of another use case for it. I'm writing to a temporary file in the PostScript renderer, too, but I don't see how your code would help me there (as an example). The code can always be moved to a different place if new use cases pop up. Hopefully you'll see when I commit the latest stuff in the AFP branch that the FileStore class can be easily extended and used to temporarily store different types of data. Other developers probably won't come across this set of classes if I hide them deeply in the org.apache.fop.render.afp, and they might spend time creating their own similar implementation. These classes have no real dependencies on FOP or AFP and could be used anywhere. Maybe in the case of the Postscript renderer it wouldn't make sense to use the new classes as the existing code is written in a very postscript output specific way and is quite closely coupled together and it would take some time to change. Related to that, I've been thinking about setting up a Wiki page for Apache Commons IO that lists IO-related classes and packages in other Apache projects so that candidates for a move to common-io can easily be identified. Sounds like a fine idea, I look forward to seeing that :). Adrian. - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Helder Magalhães for Committer
I haven't followed Batik at all either I'm afraid, so +0. Adrian. 2009/12/8 Chris Bowditch > The Web Maestro wrote: > >> Fellow Committers, >> >> As you all know, Helder Magalhães has been actively contributing to >> the Batik lists since 2008, helping users and cleaning up bugzilla. >> >> Although Helder hasn't yet exhibited his Java coding prowess, he has >> demonstrated a willingness to help others get the most out of Batik, >> and for that I'd like his efforts to be rewarded. >> >> The Apache XML Graphics Project, and the Apache Batik Project in >> particular, are a better place because of active contributors like >> Helder. So here is my vote: >> >> +1 >> >> (Votes only on gene...@... please.) >> >> Well done Helder! Keep up the good work! >> > > I haven't followed Batik, so can only vote +0. > > Chris > > > - > To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: general-h...@xmlgraphics.apache.org > >
Re: [VOTE] Pascal Sancho for Committer
Although there haven't been any code contributions of which I am aware, Pascal has made many contributions to the FOP user mailing lists and followed up bugzilla entries over a long period of time (number of years). He has also demonstrated a good knowledge of FOP, XSL:FO and digital typography in general. He is a valuable contributor to this community, maybe committership will inspire some code... :) So my vote is +1. Adrian. 2009/12/9 Max Berger > Hi *, > > I don't see the advantage of having commit rights if you do not submit > any code. But I do like the answers and bugzilla entries of Sancho. > > +0.5 > > Max > > 2009/12/9 The Web Maestro : > > Fellow Committers, > > > > As you all know, Pascal Sancho has been actively contributing to the > > FOP lists since 2004, helping users and cleaning up bugzilla to boot!. > > > > Although Pascal hasn't been actively contributing code, he has helped > > many on the FOP & XML Graphics lists, and for that I think his efforts > > should be rewarded. > > > > The Apache XML Graphics Project, and the Apache FOP Project in > > particular, are a better place because of active contributors like > > Pascal. So here is my vote: > > > > +1 > > > > (Votes only on gene...@... please.) > > > > Well done Pascal! Thank you for your efforts! > > > > Thanks, > > > > Clay > > -- > > - <http://ourlil.com/> > > My religion is simple. My religion is kindness. > > - HH The 14th Dalai Lama of Tibet > > > > - > > To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > > For additional commands, e-mail: general-h...@xmlgraphics.apache.org > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: general-h...@xmlgraphics.apache.org > > -- Kind regards, Adrian Cumiskey.
Re: Google Summer of Code: Bring out your projects
Hi Simon, My involvement with FOP these days is a little minimal due to other commitments, but in principle I would be open to the idea of acting as a mentor to a GSoC student. Adrian. On 12 March 2010 12:07, Simon Pepping wrote: > Ross Gardler of ASF announced that it is time for our projects to > start preparing for Google Summer of Code (GSoC). Do we have ideas for > GSoC projects? Are committers willing to be a mentor? > > Simon > > -- > Simon Pepping > home page: http://www.leverkruid.eu >
Re: Switching to Java 1.5
If you look through the mail archives you'll find this topic was raised numerous times over the last few years. If someone still has a good argument for why using Java 1.4 at all makes sense these days I'd be interested to hear it. +1 for Groovy (err sorry I meant 1.6...). Adrian. Sent from my iPad On Oct 21, 2010, at 3:34 AM, Glenn Adams wrote: > Any particular reason to stop at 1.5? Why not proceed to 1.6? > > G. > > On Thu, Oct 21, 2010 at 2:53 AM, Vincent Hennebert > wrote: > >> Hi, >> >> The topic has already been mentioned several times in the past, at least >> in the FOP area. The latest discussion we had was in August 2009: >> http://markmail.org/message/y7iwptehnzujcuxm >> It was decided then to release FOP 1.0 with Java 1.4 support, and do >> a user community poll shortly afterwards. >> >> More than a year has passed now and I’d like to re-visit that topic, >> with two modifications: >> • make the decision at the project level. Homogenizing things a bit >> wouldn’t hurt IMO. Specifically, Commons and FOP Trunk would switch to >> 1.5 now, Batik would switch after the 1.8 release (which is about to >> happen IIUC). >> • I’m not sure that a poll still is necessary. It’s been almost 2 years >> now that Java 1.4 has reached end of life. We are in the same >> situation as when we dropped support for Java 1.3. >> >> Moreover, I think sticking to 1.4 is a growing impediment to the >> development of the project. Simon ran into trouble when releasing 1.0: >> http://markmail.org/message/ivlwk2dcmuk25woy >> Proper internationalization can only be achieved starting from 1.5: >> http://markmail.org/message/6n2w5tefarqp76iv >> We recently upgraded Checkstyle to version 5.1 in FOP and that requires >> Java 1.5. >> >> Using retroweaving tools is doable but adds complexity to the build and >> is a hassle that I don’t think we can live with due to our limited >> resources. >> >> I think it’s time to move on. If anybody really feels that a user poll >> still is necessary, please speak up now. Otherwise, just wait a few days >> that I launch an official vote on this. >> >> Thanks, >> Vincent >> >> - >> To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org >> For additional commands, e-mail: general-h...@xmlgraphics.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: general-h...@xmlgraphics.apache.org
Re: [VOTE] The Apache XML Graphics project to switch to J2SE 1.5 as minimum environment
+1 from me, this move will hopefully encourage more community contributions. Adrian. On 2010-10-25 8:41 PM, "Web Maestro Clay" wrote: > [x] +1 Approve J2SE 1.5 as minimum environment - To unsubscribe, e-mail: gener...
Re: [VOTE] Merge XGC color branch into Trunk
I've not had time to follow so +0 from me. Adrian. On 2010-12-14 5:38 PM, "Jeremias Maerki" wrote: On 14.12.2010 10:17:04 Simon Pepping wrote: > On Tue, Dec 14, 2010 at 09:22:20AM +0100, Simon Peppin... Thanks > Note that NamedColorTest fails, but it did that already without my > patch. Fixed: http://svn.apache.org/viewvc?rev=1049003&view=rev Jeremias Maerki - To unsubscribe, e-mail: gene...
Re: [VOTE] Peter Hancock for committer
+1 from me. Adrian. On Mar 11, 2011, at 3:23 AM, Vincent Hennebert wrote: > Yes, this is well deserved. > > +1 > > Vincent > > > On 10/03/11 14:45, Chris Bowditch wrote: >> Fellow Committers, >> >> As you all know Peter Hancock has been actively participating in the mailing >> lists since 2009, see: http://marc.info/?l=fop-user&m=125778454424550&w=2 >> >> Peter has also submitted several patches, some of which have been committed. >> A >> quick search of bugzilla identified the following patches submitted by Peter: >> 48636, 48954, 48955, 49097, 49893, 49913, 50391, and 50909 >> >> Here's my +1 >> >> Thanks, >> >> Chris > > - > To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: general-h...@xmlgraphics.apache.org > - To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: general-h...@xmlgraphics.apache.org
Re: [VOTE] Glenn Adams for committer
+1 On 20 February 2012 07:51, Jeremias Maerki wrote: > +1 > > On 20.02.2012 10:16:57 Chris Bowditch wrote: > > Hi All, > > > > Glenn Adams is the author of the Complex Scripts branch for FOP. He has > > been developing it for over 1 year now, providing regular updates to the > > patch as well as support for it via the fop-users Mailing List. I > > therefore propose Glenn is made a committer as reward for his dedication > > to the FOP project. Glenn is an expert in eastern languages (amonst > > other things) and will bring a wealth of valuable knowledge to the FOP > > development team. > > > > +1 from me. > > > > Votes on general@ only please. > > > > Thanks, > > > > Chris > > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: general-h...@xmlgraphics.apache.org > >
Re: [VOTE] Include Jeremias' PDF plug-in library as a new sub project
+1 On 9 March 2012 03:47, Chris Bowditch wrote: > Fellow PMC Members and committers, > > As you are all aware, Jeremias currently hosts a PDF plug-in for loading > PDFs as images within FOP. The download for the plug-in is available on > Jeremias' website. Some of our committers including (but not limited to) > Mehdi and Peter have needed to make some improvements to the plug-in. So we > did that to a local copy of the code downloaded from Jeremias' website a > couple of years ago. We sent the changes back to Jeremias, but ran into > some problems since our copy is now behind Jeremias' copy. Jeremias agreed > to make the repository public at apache-extras.org. This strikes me as a > sub-optimal solution. FOP and PDFBox both live in Apache, so why can't we > have the plug-in code as a 4th sub project of XML Graphics? I suggested > this to Jeremias and he has agreed to donate the code to Apache. I > therefore table a vote on this motion. > > Here's my +1. > > The vote will run for 7 days until 10am 16th March. > > Thanks, > > Chris > > --**--**- > To unsubscribe, e-mail: > general-unsubscribe@**xmlgraphics.apache.org > For additional commands, e-mail: > general-help@xmlgraphics.**apache.org > >
