I’m using DocBook XSL 1.7.2.0 with FOP 0.93. When I generate a PDF, the indexterm elements have extra whitespace (from line breaks and tabs). I successfully removed the whitespace by editing one of the DocBook stylesheet templates. However, the page numbers in the index are missing. Also, FOP warns about unresolved ID references, such as this warning: WARNING: Page 9: Unresolved id reference "d0e127" found. When I open the FO file, here’s what one of the index entries looks like: <fo:block xmlns:fox="http://xmlgraphics.apache.org/fop/extensions">Administration Console, <fo:basic-link internal-destination="d0e127"><fo:page-number-citation ref-id="d0e127"/></fo:basic-link></fo:block Here’s the internal destination it’s pointing to in the file: <fo:inline id="d0e127"><!--Administration Console--></fo:inline> As you can see, it’s an empty <fo:inline> marker, which is what I expect. However, FOP cannot resolve the reference. Jeff Powanda jpowanda@vocera.com
Created attachment 20398 [details] IndexTest.xml FO file that demonstrates problem with empty <fo:inline> index markers
This is not really a problem. It is a very minor warning log message that will only occur in this particular situation. It occurs because ids are tracked only for content that actually takes up space on the page output. Anything else is ignored/discarded. There is no application error here, its just an unwanted warning message - so I suggest we ignore it for now. Adrian.
> This is not really a problem. It is a very minor warning log message that will > only occur in this particular situation. It occurs because ids are tracked only > for content that actually takes up space on the page output. Anything else is > ignored/discarded. FYI (and that of people who find this bug on google) DITA Open Toolkit 1.4 produces empty <fo:inline> index markers for all table-of-contents entries, on the grounds that TOC references are point references and so should not correspond to a region of actual space on the page output. This does not work with FOP 0.94. To work around, edit DITA/xslfo/dita2fo-titles.xsl and DITA/xslfo/dita2fo-subroutines.xsl to put the zero-width breaking space entity ​ in the inlines.
Flagged as bug 1822157 on dita-ot https://sourceforge.net/tracker/index.php?func=detail&aid=1822157&group_id=132728&atid=725074
Right, this is a bug. Since I don't have time right now to fix this, here's what needs to be done: fo:inline, like fo:block, can be empty but carry an "id" that can be referenced. For the "id" to survive until the rendering time, the InlineLayoutManager has to create a zero-length Knuth box for the empty FO in a similar ways as we do it for fo:block in BlockStackingLayoutManager: //Empty fo:block, zero-length box makes sure the IDs are registered. returnList.add(new KnuthBox(0, notifyPos(new Position(this)), true)); The reason for this: If there's no Knuth box for a particular formatting object, the area creation stage (addAreas()) is not done and therefore the IDs are not registered on the current page. There are probably other inline FOs that need this treatment, too. Better find that out first, create a test case and fix all together.
(In reply to comment #5) > Right, this is a bug. Since I don't have time right now to fix this, here's what > needs to be done: OK, I'll look into it. I'm looking into getting fo:markers working for inlines as well, and already ran into this very obstacle (as well as some others).
Just been looking into this one a bit more closely, and got it working, but the problem here was hidden a bit deeper... Empty inlines, up to now, did not even generate a LayoutManager (see: org.apache.fop.layoutmgr.LayoutManagerMapping, around line 270). Now that this has been traced, adding an empty InlineKnuthSequence if the inline has no content, seems to fix the issue. Expect the fix to be committed to the trunk soon.
Fixed in FOP trunk. see: http://svn.apache.org/viewvc?rev=591437&view=rev Thanks for reporting!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed