You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/05/19 14:33:05 UTC
A small XMP framework
(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
---------------------------------------------------------------------
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
Re: A small XMP framework
Posted by Simon Pepping <sp...@leverkruid.eu>.
Interesting. XMP has been around for a while and has a powerful
sponsor in Adobe. Nevertheless, it does not seem to have gained a
large following. When a short while ago Adobe proposed XMP as a
standard for metadata in OpenOffice.org, it met with much
criticism. One point of criticism is that it has rules and limitations
which are rather unnatural in RDF terms.
I noticed this when I investigated XMP as a standard for inclusion of
metadata of publications in PDF. These are a few links that I
consulted:
http://www.snee.com/bobdc.blog/2005/12/using_or_not_using_adobes_xmp.html,
http://www.ldodds.com/blog/archives/000261.html,
http://www.ldodds.com/blog/archives/000263.html,
http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2005/12/07/opendocument-and-xmp,
http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2005/12/09/odf-and-xmp-comments.
At that time we were also pointed to this site,
http://www.xmp-open.org/, which is an effort to provide a broader
basis to XMP.
That all said, I am aware that XMP plays a role in various PDF
standards. And even if that were not the case, I am not at all against
an implementation in xmlgraphics-commons. If I have done my research
well, when completed it will be one of the few decent implementations
available. Adobe's own SDK provides minimal support, only in C++.
Regards, Simon
On Fri, May 19, 2006 at 02:33:05PM +0200, Jeremias Maerki wrote:
> (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
>
>
> ---------------------------------------------------------------------
> 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
>
--
Simon Pepping
home page: http://www.leverkruid.eu
---------------------------------------------------------------------
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
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
So, I've uploaded the initial batch of the XMP metadata framework. I've
already successfully integrated it locally with FOP for handling all
essential XMP-related tasks (including metadata merging). I've also
incorporated some of Glen's feedback.
I guess I will do a snapshot of XML Graphics Commons tomorrow and commit
my outstanding changes in FOP for PDF/A support after some more testing.
I still hope for Ben's feedback on my approach.
On 15.06.2006 12:13:47 Jeremias Maerki wrote:
> I've had no feedback in a week. Is everybody comfortable if I commit the
> code to the XML Graphics Commons repository as presented in the snapshot
> ZIP? If I hear no objections within 72 hours, I'll go ahead.
>
> On 07.06.2006 10:53:35 Jeremias Maerki wrote:
> > I've just uploaded my XMP approach for review. Of course, it's far from
> > being complete or bug-free. But it presents a proof-of-concept although
> > I haven't implemented structured properties.
> >
> > Download:
> > http://www.jeremias-maerki.ch/download/fop/xmlgraphics-commons-snapshot.zip
> >
> > Usage examples can be found in the examples directory. The source code
> > is in the org.apache.xmlgraphics.xmp package.
> >
> > Feedback is welcome. We can then decide which way to go.
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
Re: A small XMP framework
Posted by Glen Mazza <gm...@apache.org>.
I unfortunately don't know much about XMP (I did look a little bit at
the Adobe links you had given earlier though), but here are a few
code-comments independent of the subject material at hand:
1.) I would recommend any methods named in a JavaBeans fashion that you
may have to be purely for setting a private member variable or
retrieving the same private member variable. For example, in your
DublinCoreAdapter,
public void setTitle(String value, String lang) {
setLangAlt("title", value, lang);
}
This is not really setting a private String value named Title. It is
actually adding to some array of some sort. I think "addTitle()" or
similar would be clearer here. As-is, when I look at the caller, for
example, MetadataFromScratch:
dc.setTitle("Der Herr der Ringe", "de");
dc.setTitle("Lord of the Rings", "en");
It causes the reader of the code to think that the second call may be
overwriting the value of the first call. So something like
"addTitle()" instead would help readability IMO.
2.) Offhand, XMPComplexValue looks like a candidate for being an
interface instead of an abstract base class. It only has two methods,
both abstract.
3.) I noticed several "//" commenting-out of code, some of which looks
like you will never be restoring it (throwaway code). If you haven't
already, it would be nice if you could quickly search on "//" within the
newly added files to make sure each have a reasonable chance of someday
being reactivated, else just remove the commented-out code entirely.
4.) Will the system *ever* run without an instance of XMPSchemaRegistry
being activated? Within that class the Singleton instance is
instantiated only upon the first call to getInstance(), leaving vague
its necessity. But if there is always going to be such an instance, you
might wish to instantiate via
static {
instance = new XMPSchemaRegistry();
}
instead to emphasize that this object will always be created.
5.) In XMPProperty:getEffectiveQName(), I suspect a user-friendly error
should be given if the namespace is not available within the
XMPSchemaRegistry instead of an NPE. (i.e., if
"XMPSchemaRegistry.getInstance().getSchema(getNamespace());" returns null)
Also, I don't know the logic, but for XMPProperty:getArrayValue() below,
I think a simple class cast exception or a more user-friendly message
might be a better idea then just silently returning null, iff the callee
should know in advance not to call getArrayValue() if it hasn't already
configured the value to be an XMPArray.
public XMPArray getArrayValue() {
return (value instanceof XMPArray ? (XMPArray)value : null);
}
6.) Also, for XMPArray.getSimpleValue(), same issue as immediately
above but what if you have a one-element XMPArray? I think the below
will return getValue(0) rather than the null (or error message) I think
you would like here:
public Object getSimpleValue() {
if (values.size() == 1) {
return getValue(0);
} else {
return null;
}
}
If I'm correct, I think you would want to test on "values instanceof
XMPArray" instead.
7.) In XMPSchemaAdapter.formatISO8601Date(): variables dt, zoh, and
zom should probably be spelled out to make it more readable. I'm not
even sure what zoh and zom mean. (hours and minutes, OK, but "zo" is
unclear to me.)
Glen
Jeremias Maerki wrote:
>I've had no feedback in a week. Is everybody comfortable if I commit the
>code to the XML Graphics Commons repository as presented in the snapshot
>ZIP? If I hear no objections within 72 hours, I'll go ahead.
>
>On 07.06.2006 10:53:35 Jeremias Maerki wrote:
>
>
>>I've just uploaded my XMP approach for review. Of course, it's far from
>>being complete or bug-free. But it presents a proof-of-concept although
>>I haven't implemented structured properties.
>>
>>Download:
>>http://www.jeremias-maerki.ch/download/fop/xmlgraphics-commons-snapshot.zip
>>
>>Usage examples can be found in the examples directory. The source code
>>is in the org.apache.xmlgraphics.xmp package.
>>
>>Feedback is welcome. We can then decide which way to go.
>>
>>
>
>Thanks,
>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
>
>
>
>
---------------------------------------------------------------------
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
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've had no feedback in a week. Is everybody comfortable if I commit the
code to the XML Graphics Commons repository as presented in the snapshot
ZIP? If I hear no objections within 72 hours, I'll go ahead.
On 07.06.2006 10:53:35 Jeremias Maerki wrote:
> I've just uploaded my XMP approach for review. Of course, it's far from
> being complete or bug-free. But it presents a proof-of-concept although
> I haven't implemented structured properties.
>
> Download:
> http://www.jeremias-maerki.ch/download/fop/xmlgraphics-commons-snapshot.zip
>
> Usage examples can be found in the examples directory. The source code
> is in the org.apache.xmlgraphics.xmp package.
>
> Feedback is welcome. We can then decide which way to go.
Thanks,
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
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've just uploaded my XMP approach for review. Of course, it's far from
being complete or bug-free. But it presents a proof-of-concept although
I haven't implemented structured properties.
Download:
http://www.jeremias-maerki.ch/download/fop/xmlgraphics-commons-snapshot.zip
Usage examples can be found in the examples directory. The source code
is in the org.apache.xmlgraphics.xmp package.
Feedback is welcome. We can then decide which way to go.
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
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 06.06.2006 16:59:23 Ben Litchfield wrote:
> I agree that I have been less than happy with the DOM backed structure,
> it has made for a less than friendly client interface to
> create/manipulate XMP data. My original thought was to model it similar
> to the way PDFBox backs to source objects but in this case it is not as
> practical and complicates things. Once you are at a good point and get
> stuff in the repository I can help writing some of specific schemas.
Very good. I'm at my last point of investigation before I'll publish
what I've done so far. I'm currently implementing a facility to specify
merging behaviour for certain properties. Certain properties will simply
be overwritten (like pdf:Producer), while others will contribute
additional values (like dc:date).
> I would also like to work on getting PDFBox incubated, it is my
> understanding that the first step is to be nominated by a champion(I
> assume that's you :) ), then with any luck we will find a sponsor. I am
> still reviewing the incubation docs to get a full understanding of the
> process.
Yes, I can serve as champion if noone else is found. But I have too much
going on already so I'm a bit hesitant to take on yet another
responsibility. So only, if necessary. I assume the prime candidate for
a sponsor is the XML Graphics PMC. How big is the currently active set
of people on PDFBox?
<snip/>
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
Re: A small XMP framework
Posted by Ben Litchfield <be...@benlitchfield.com>.
I agree that I have been less than happy with the DOM backed structure,
it has made for a less than friendly client interface to
create/manipulate XMP data. My original thought was to model it similar
to the way PDFBox backs to source objects but in this case it is not as
practical and complicates things. Once you are at a good point and get
stuff in the repository I can help writing some of specific schemas.
I would also like to work on getting PDFBox incubated, it is my
understanding that the first step is to be nominated by a champion(I
assume that's you :) ), then with any luck we will find a sponsor. I am
still reviewing the incubation docs to get a full understanding of the
process.
Ben
Jeremias Maerki wrote:
> After too much distraction last week I finally managed to dive in. I've
> looked at Ben's code. His code operates directly on a W3C DOM. I've had
> my negative experiences with the W3C DOM but the same applies to SAX.
> Anyway, while playing with JempBox I've had quite a few "NAMESPACE_ERR:
> An attempt is made to create or change an object in a way which is
> incorrect with regard to namespaces" errors. This has to do with all the
> namespace declarations.
>
> I then decided to find out which way I'd go if I started from scratch. I
> started by modelling the XMP data model in Java objects (without a DOM)
> and wrote a SAX-based parser. The data model was then taught to render
> itself to SAX events. The next step is to write schema support like Ben
> has already done. I think my approach makes it easier to build a data
> model that allows merging of two metadata trees. This is important in
> the case of FOP. For example, I don't hold "rdf:Description" elements in
> the data model. Metadata is simply a single bag of properties. The
> properties are grouped into Description elements as recommended by the
> XMP spec during serialization.
>
> To get a more structured approach to this I've set up a Wiki page [1]
> for the topic. The most important thing there are the requirements that
> should give us directions. If I forgot anything please add it. I'll play
> around with my package for a little bit and will then publish it for
> review before we go any further (like committing to the repository).
>
> [1] http://wiki.apache.org/xmlgraphics/ExtensibleMetadataPlatform
>
>
> On 22.05.2006 22:59:03 Jeremias Maerki wrote:
>
>> 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
>
>
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
After too much distraction last week I finally managed to dive in. I've
looked at Ben's code. His code operates directly on a W3C DOM. I've had
my negative experiences with the W3C DOM but the same applies to SAX.
Anyway, while playing with JempBox I've had quite a few "NAMESPACE_ERR:
An attempt is made to create or change an object in a way which is
incorrect with regard to namespaces" errors. This has to do with all the
namespace declarations.
I then decided to find out which way I'd go if I started from scratch. I
started by modelling the XMP data model in Java objects (without a DOM)
and wrote a SAX-based parser. The data model was then taught to render
itself to SAX events. The next step is to write schema support like Ben
has already done. I think my approach makes it easier to build a data
model that allows merging of two metadata trees. This is important in
the case of FOP. For example, I don't hold "rdf:Description" elements in
the data model. Metadata is simply a single bag of properties. The
properties are grouped into Description elements as recommended by the
XMP spec during serialization.
To get a more structured approach to this I've set up a Wiki page [1]
for the topic. The most important thing there are the requirements that
should give us directions. If I forgot anything please add it. I'll play
around with my package for a little bit and will then publish it for
review before we go any further (like committing to the repository).
[1] http://wiki.apache.org/xmlgraphics/ExtensibleMetadataPlatform
On 22.05.2006 22:59:03 Jeremias Maerki wrote:
>
> 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
Re: A small XMP framework
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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