Fop
  1. Fop
  2. FOP-1380

FOP 0.93 is not resolving empty <fo:inline> index markers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.93
    • Fix Version/s: None
    • Component/s: pdf
    • Labels:
      None
    • Environment:
      Operating System: Windows Server 2003
      Platform: All
    • External issue ID:
      42748

      Description

      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

      1. IndexTest.xml
        100 kB
        Jeff Powanda

        Activity

        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed
        Hide
        Andreas L. Delmelle added a comment -

        Fixed in FOP trunk. see: http://svn.apache.org/viewvc?rev=591437&view=rev

        Thanks for reporting!

        Show
        Andreas L. Delmelle added a comment - Fixed in FOP trunk. see: http://svn.apache.org/viewvc?rev=591437&view=rev Thanks for reporting!
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        (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).

        Show
        Andreas L. Delmelle added a comment - (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).
        Hide
        Jeremias Maerki added a comment -

        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.

        Show
        Jeremias Maerki added a comment - 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.
        Show
        David Linton added a comment - Flagged as bug 1822157 on dita-ot https://sourceforge.net/tracker/index.php?func=detail&aid=1822157&group_id=132728&atid=725074
        Hide
        David Linton added a comment -

        > 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.

        Show
        David Linton added a comment - > 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.
        Hide
        Adrian Cumiskey added a comment -

        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.

        Show
        Adrian Cumiskey added a comment - 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.
        Hide
        Jeff Powanda added a comment -

        Attachment IndexTest.xml has been added with description: IndexTest.xml FO file that demonstrates problem with empty <fo:inline> index markers

        Show
        Jeff Powanda added a comment - Attachment IndexTest.xml has been added with description: IndexTest.xml FO file that demonstrates problem with empty <fo:inline> index markers

          People

          • Assignee:
            fop-dev
            Reporter:
            Jeff Powanda
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development