The outline is ok. As an alternative ..incubator/pdfbox could be moved to ..incubator/pdfbox/main if we don't merge all three.
As noted some time ago, XML Graphics Commons (XGC) has an XMP facility that's more or less equivalent to JempBox, but it's not yet available as a separate JAR (with only XMP stuff). Gut feeling is that XGC is slightly stronger than JempBox but I'm biased. OTOH, I believe that XGC has a few things that PDFBox could also use in time (like the image loader framework [1][2]). Anyway, one of my priorities, now that PDFBox is set up, is to write a set of Metadata adapters which enable XMP reading/writing against XGC's XMP stuff and Adobe's XMP library. If in any way possible, I'd really like to consolidate XMP handling inside ASF projects. I'll do that as a proposal with code. Whether this is accepted by the various communities is a different story. I do envision a Apache Commons component. Please stop me if this is a silly idea. Of course, XGC could also simply be reused but the XMP classes might not be as complete as Adobe's XMP toolkit. [1] http://xmlgraphics.apache.org/commons/image-loader.html [2] Using the image loader framework, PDFBox could do things like loading SVG and WMF images (if FOP and Batik are in the classpath) and embed them in the PDF. Or it can easily support embedding Barcodes when I've written image converters for Barcode4J. MathML support with JEuclid etc. etc. This stuff is pretty powerful. Concerning the font stuff: FOP has extensive font code that is destined to move to XGC (when I finally get my affairs to together to start it). Batik, too, has code to read TrueType fonts. So, some overlap with FOP is already there. FontBox adds to that. That said, I'm not sure consolidation is very easy since besides me I don't see many other people who would help to push that. I have to choose my priorities carefully. I'm stretched thin already. FontBox is sufficiently separate from the whole PDF topic that it makes sense to keep it as a separate subproject. This encourages a clean separation. If anyone can make use of FontBox outside the PDFBox context, all the better. I'm currently leaning towards this: Consolidate XMP stuff from XGC and JempBox into an Apache Commons component and discard JempBox. Or just use XGC. Leave FontBox as subproject to PDFBox with a separate JAR as dependency for PDFBox. I'm eager to hear other opinions and ideas. On 05.08.2008 16:21:40 Jukka Zitting wrote: > Hi, > > Just a quick outline of the SVN structure I came up with: > > * The main PDFBox codebase has its trunk,tags,branches structure right > below https://svn.apache.org/repos/asf/incubator/pdfbox. > > * The FontBox codebase has a separate trunk,tags,branches structure > below https://svn.apache.org/repos/asf/incubator/pdfbox/fontbox. > > * The JempBox codebase has a separate trunk,tags,branches structure > below https://svn.apache.org/repos/asf/incubator/pdfbox/jempbox. > > Note that the FontBox and JempBox codebases still need to be cleaned > for svn:eol-style settings, etc. > > Should we keep FontBox and JempBox as separate codebases or perhaps > merge them into the main PDFBox codebase? In other words, are there > many (potential) users for those projects outside PDFBox? > > If we keep FontBox and JempBox separate, then I guess we should also > set up separate Jira projects for them and start planning for the > respective initial org.apache.* releases. > > BR, > > Jukka Zitting Jeremias Maerki
