Uploaded image for project: 'FOP'
  1. FOP
  2. FOP-1348

[PATCH] Exact positioning of PDF internal links


    • Type: Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: renderer/pdf
    • Labels:
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:


      This patch re-implements the full internal link functionality in the PDF output.
      Bookmarks, basic-links and named destinations again point to the exact spot
      instead of the top of the page. The intermediate area tree XML format is also
      supported (except for named destinations).

      The target PageViewport is still determined during the layout phase; the on-page
      position is calculated in PDFRenderer. Note that the code could be greatly
      simplified if we moved everything to the renderer. This wouldn't break anything
      in FOP, but it would prevent custom renderers from getting the target
      PageViewport key. The patch itself also breaks renderers who pick up that key
      (as the type of the InternalLink trait has changed), but not beyond repair: all
      that's needed is a minor code change wherever that trait is read and the caller
      expects a String.

      The vast majority of changes are in PDFRenderer, PDFFactory, XMLRenderer and
      AreaTreeParser. But some other modifications were also required (or at least
      highly desired). The most important of them are:

      • PageViewport needs to know for what IDs it is the first PV, independently of
        ATH. This info is needed in the renderer.
      • The dummy area generated by a fo:wrapper must be added to the area tree, at
        least if it has an ID. (DocBook generates empty wrappers for <indexterm>s.)
        [Note: I kept this a "generic" InlineArea. But maybe it would be better to
        create a subclass, e.g. DummyInlineArea.]
      • Two extra constructors for BookmarkData, for stuff read back from the area
        tree XML. Also made the tagging of subdata as "unresolved" conditional, because
        bookmarks read from AT XML are already resolved.
      • To avoid code duplication (and divergence), the actual adding of an
        INTERNAL_LINK trait to an area is now done exclusively in the LinkResolver.
      • Created an additional constructor for PDFDestination.
      • New method PDFState.getBaseTransform() returns the transformation to be used
        for fixed-positioned areas.

      I also added some helper functions here and there to move duplicated code into
      (esp. in PDFFactory). And on at least two occasions I changed existing comments
      because they puzzled me rather than helping me understand the purpose of the
      commented-upon object. Whether all these changes are acceptable is of course up
      to the team. If any changes or extensions are required, I'm willing to provide them.


        1. check-comma.patch
          0.8 kB
          Paul Vinkenoog
        2. Trait.diff
          1 kB
          Adrian Cumiskey
        3. Trait.diff
          1 kB
          Adrian Cumiskey
        4. internal-destination.patch
          83 kB
          Paul Vinkenoog
        5. internal-destination.patch
          78 kB
          Paul Vinkenoog

          Issue Links



              • Assignee:
                fop-dev@xmlgraphics.apache.org fop-dev
                paul@vinkenoog.nl Paul Vinkenoog
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: