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)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
