Bug#570095: Patch for fop bug

[Vincent Fourmond]

brian m. carlson wrote:
> 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.

  Whaouh, thanks !

  Mathieu, I've just uploaded a package with a fix to experimental.
Would you mind trying if that works for you, before I upload to unstable
? (just being my usual paranoid ;-)...)

  Many thanks again !

	Vincent

-- 
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
 -- Bjarne Stroustrup

Vincent, listening to Kerfautras (Matmatah)