On 09.12.2004 08:27:18 Victor Röder wrote:
> Hi Jeremias,
> > you haven't told us what branch you are on. Are you on the maintenance
> > branch or on FOP HEAD?
> I suppose I'm working with the 0.20.5 code base...
> > These hints are targeted at FOP HEAD code but some can be applied to the
> > maintenance branch, too, although the whole mechanism is quite different
> > there.
> I didn't had the chance to look at the HEAD branch yet. Is it in an
> stable/usable state?

Usable? Depends. :-) Stable? No. It's where we concentrate all our
efforts because the old maintenance branch is a dead end. The design of
the layout engine doesn't allow any further progress towards full
specification compliance. That's why we decided to freeze the
maintenance branch. We're hoping for any help we can get to bring the
redesign effort to a point where we can release again. I'm pretty
certain now, that will happen sometime next year, but not before summer.

> > One thing you will have to do is creating an ElementMapping class (plus
> > node subclasses, or you extend the existing ExtensionElementMapping) so
> > the FOTreeBuilder can create nodes for each XML element of the various
> > namespaces in the metadata part. A good example in your case is the
> > bookmarks support code you can find in the org.apache.fop.fo.extensions
> > package. There you have an example of an ElementMapping class
> > (ExtensionElementMapping) and node classes (Bookmarks/Outline). That's
> > the first step.
> I tried to build up a separated DOM with the XMP data in it (similarly to
> the SVG stuff). But I think there are several restrictions so that I doubt
> that this could be done with the 0.20.5 sources.
> Examples: 1) There is no way to define an own PropertyHandler. There are two
> for FO and SVG, but they are in the fop.jar as class files. 2) The SAX
> parser does not submit the prefix bindings for namespaces (e.g.
> xmlns:xap="http://ns.adobe.com...";) as attributes. They are missing in the
> PropertyList. 3) Leaf text nodes are not submitted to
> FObj.addCharacters(...).

Hmmmmm.... My guess is that you didn't take the right approach. See
below for an example of an external FOP extension. It could be, however,
that the old code (and maybe even the new) doesn't handle namespace
prefixes in attributes well.

> > I'm not sure if attaching the metadata to a page-sequence is the right
> > approach. The page-sequence itself isn't represented in the resulting
> > PDF. You might also have multiple page-sequences in a document. So
> > you should probably attach it to fo:root where it applies to the whole
> > document. Attaching metadata to individual pages or objects is probably
> > trickier.
> Yes, you're right. Attaching it to the 'root' and to a 'block' or
> 'foreign-instream-object' is sounder.
> > This should give you a few pointers into the code. I'm not sure if I got
> > everything right, because I'm not so familiar with this part, yet.
> > Hopefully, my colleagues will correct me if I wrote anything wrong.
> Thanks, it helped me out. But I don't think that the 0.20.5 sources will get
> me any further... Btw: Did you notice that it does not compile if you remove
> the fop.jar with compiled sources from the classpath? There seem to be
> inconsistent packages between the fop.jar and the actual source directory
> tree.

Not sure, but could it be that you're forgetting that during the build
process code gets generated using XSLT in the build/codegen directory?
At least, I don't see any problems with the maintenance branch build.

> > I hope this helps nonetheless. We're looking forward to your patches for
> > FOP HEAD. ;)
> Well, we'll see :-). One request: Please do not see SVG as the *only*
> foreign XML vocabulary that one could embed in FO :-).

We don't. For example, I'm the author of Barcode4J which has a FOP
extension that enables you to use a special namespace to specify a
barcode in an fo:instream-foreign-object. It didn't even have to modify
the source code to implement this. See:


Maybe the source code of that FOP extension might help you because they
do pretty much what you're trying to do: building a DOM from the
elements in the extension namespace.


I'm sorry that I don't have more time right now to dive in further but
maybe this helps.

Jeremias Maerki

Reply via email to