xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: A small XMP framework
Date Mon, 22 May 2006 20:59:03 GMT

On 22.05.2006 21:27:04 Ben Litchfield wrote:
> Sorry for the delay in response, been quite busy lately.

I know the feeling. :-)

> I am so interested that I actually started a project just last month, 
> it is currently hosted on SF at http://www.sf.net/projects/jempbox

LOL. Good thing I thought about you before taking off.

> AFAIK, there are no open source Java XMP libraries, and I think there 
> is only 1 commercial one for that matter so I started it.

Actually, iText has some code, I think.

> I would gladly give any/all JempBox code to XML Graphics Commons, or 
> collaborate on a new design.

That's very generous. I'm most interested in working together with you
on this. I'll take a look at your sources ASAP and will think about how
best to continue here. There are more than 2 possibilities:

- I work with you in your SourceForge project and we use the package in
XML Graphics. The license is ok for us but I guess we're probably in
favor of having the code in the vicinity. At least, I am.
- You donate to the sources to the XML Graphics project (IP clearing
process should be simple is this case [1]).
- We start again from scratch in XML Graphics Commons. I don't prefer
that in case your code is already a good start (which I assume).
- A full incubation as a new subproject would allow you to get direct
committership but an XMP component alone would probably not have enough
critical mass by itself. A full incubation of PDFBox with associated
components (including XMP) might be another idea. However, here's where
I'd stretch myself too thin at the moment. I'd need additional help from
within the ASF. But we could simply drop the hint in the Incubator.
Maybe we'll be surprised how many fish bite.

The problem from your POV when simply donating the sources is that
following the Apache way you'd have to earn your committer status first.
With the recent AFP renderer donation, the two original developers
didn't get committer status right away. That may seem a little unfair
however they were happy that way. They are more than welcome to join the
development and I'm sure they get priority consideration for committer
status if they become active. So, given what you've achieved with PDFBox,
committer status is probably something the can happen fairly quickly in
your case because you obviously know how open source works. I guess I
should ask on the Incubator list how they see a case like this. I'm open
to any solution. But it doesn't depend on me alone. All XML Graphics
people should be happy with the way we're dealing with this.

[1] Dealing with the ASF unfortunately means that you have to deal with
a number of bureaucratic hurdles all of which are designed to hold the
quality of Apache products high. It's much more easy to start a project
on SourceForge. That's important to know.

> Ben
> 
> 
> 
> > (cc'd Ben Litchfield, project admin of PDFBox, because he might be
> > interested, too)
> > 
> > I'm about to start a little XMP framework (parser, DOM, merger, 
> writer)
> > which I need to finalize PDF/A (and later PDF/X) support for FOP. XMP 
> is
> > a subset of RDF defined by Adobe to provide a metadata storage format
> > that is universally usable in many formats, PDF only being one of 
> them.
> > It can also be used with SVG and XSL-FO, although for the latter there
> > are no recommendations on the placement of XMP metadata. This is
> > something I will want to address when I gathered some experience with
> > this topic.
> > 
> > Since this XMP framework will be rather small and since it's not
> > FOP-specific I wanted to ask if anyone is against my implementing it 
> as
> > part of XML Graphics Commons (org.apache.xmlgraphics.xmp)? I don't 
> plan
> > to use any RDF libraries as the XMP's RDF subset should be easily
> > manageable with minimal code, i.e. no external dependencies other than
> > JAXP's APIs.
> > 
> > The main reason why I need this is that it should be possible to 
> specify
> > XMP inside an XSL-FO document. FOP should then use this info to 
> populate
> > the PDF Info object as well as the PDF Metadata object for the 
> document.
> > The metadata needs to be enriched with additional values which is why 
> I
> > need a parser and a easy-to-use in-memory representation.
> > 
> > The thing could also be interesting for Batik, in case anyone wishes 
> to
> > port metadata from SVG over to the generated output files (PDF, EPS, 
> PNG,
> > TIFF etc.).
> > 
> > Links:
> > - http://www.adobe.com/products/xmp/index.html
> > - http://partners.adobe.com/public/developer/xmp/sdk/index.html
> > 
> > Feedback and help welcome.
> > 
> > Jeremias Maerki


Jeremias Maerki


---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message