Bug#570095: Patch for fop bug

[brian m. carlson]

tags 570095 + patch
kthxbye

I *believe* that normally fop omits empty fo:inline elements.  However,
in this case, fop can't do that, since the element in question has an id
attribute, which might be referenced by something else.

As a consequence, in the failing function, currLM is null, where it
would normally be non-null.  However, a sanity check is missing, and
therefore the code matches the currLM == prevLM condition (since they're
both null) and prevLM has a method called on it.  Boom.

I don't really understand the fop code here very well, so I've basically
had it punt if currLM is null: it simply moves onto the next iteration
of the loop.  My debugging leads me to believe that the length of
oldList only ever has one element in this case, so this does not appear
to break anything.

I've tested with the DocBook 5 example, as well as an extended version
that actually references the anchor, and both appear to result in PDFs
that are acceptable to Evince.  In the latter case, the link works
correctly.

It also, AFAICT, builds other PDFs correctly as well, so I'm not too
terribly concerned about breakage.  Patch is attached.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fop.patch
Type: text/x-diff
Size: 947 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20100217/06a8b59c/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20100217/06a8b59c/attachment.pgp>