Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
2.5
-
None
-
None
-
Operating System: All
Platform: All
-
42067
Description
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.
Attachments
Attachments
Issue Links
- is duplicated by
-
- Closed