Can somebody please test the files I deposited here? http://people.apache.org/~jeremias/fop/dest-test/
Those are made from Paul's FO files. I took a look myself and compared the current behaviour to what was in 0.20.5. First observation: Adobe Acrobat doesn't list any destinations when the PDF is created with FOP Trunk, but it does if you generate the PDF with FOP 0.20.5. So I went into the PDF.... Snippet from FOP 0.20.5: 2 0 obj << /Type /Catalog /Pages 1 0 R /Names << /Dests << /Names [ (page1) [ 6 0 R /XYZ -5.0 365.0 null ] (page2) [ 8 0 R /XYZ -5.0 365.0 null ] ] >> >> >> endobj Snippets from FOP Trunk before my modifications: 16 0 obj <</Limits [(page1) (page1)] /Names [(page1) 17 0 R] >> endobj 18 0 obj <</Limits [(page2) (page2)] /Names [(page2) 19 0 R] >> endobj 21 0 obj << /Limits [(page1) (page2)] /Kids [16 0 R 18 0 R] >> endobj 22 0 obj << /Dests 21 0 R >> endobj 2 0 obj << /Type /Catalog /Pages 1 0 R /Names 22 0 R /Metadata 7 0 R >> endobj 17 0 obj << /Type /Action /S /GoTo /D [8 0 R /XYZ 0.0 360.0 null] >> endobj 19 0 obj << /Type /Action /S /GoTo /D [13 0 R /XYZ 0.0 360.0 null] >> endobj I don't see anything obviously wrong. But following a suspicion I've done an experiment and flattened the name tree......and the destinations suddenly appear in Adobe Acrobat and my own tests show that destinations seem to work. Snippets from FOP Trunk AFTER my modifications: 19 0 obj << /Dests << /Names [(page1) 16 0 R (page2) 17 0 R] >> >> endobj 2 0 obj << /Type /Catalog /Pages 1 0 R /Names 19 0 R /Metadata 7 0 R >> endobj 16 0 obj << /Type /Action /S /GoTo /D [8 0 R /XYZ 0.0 360.0 null] >> endobj 17 0 obj << /Type /Action /S /GoTo /D [13 0 R /XYZ 0.0 360.0 null] >> endobj I've made quite a few changes in addition to this change: I fixed a few style issues and removed a newly introduced dependency from the PDF library into the area package (DestinationData and PageViewport). So, before I commit this, I'd like to know if, with my modifications, any of you see similar improvements as I do. Thanks. On 11.04.2007 13:29:59 Paul Vinkenoog wrote: > Last update for now: > > >> - When I link to those destinations as relative URLs, like this: > >> > >> external-destination="nbackup.pdf#nbackup-dochist" > >> > >> then sometimes my browser opens the document on the right spot, and > >> sometimes it opens at the top of the file. This is independent of > >> the link, i.e. if a click again on an already visited link, it may > >> turn out right where it first was wrong, or vice versa. > >> The browser always displays the intended location in the URL bar, > >> even if it went top-of-file: > >> > >> file:///F:/FOP/FO-files/nbackup.pdf#nbackup-dochist > > After putting the files online, everything worked perfectly - for a > while. Only after lots and lots of clicking did Firefox seem to get > confused and started to land on wrong spots (either top of file, or > another existing named destination.) > > MSIE made a mess of it right from the start. > > In case anybody wants to play with this, the files are at: > > http://vinkenoog.nl/test/ > > The one containing the links is dests.pdf, the target file is > nbackup.pdf > > .fo sources are also there, as well as Jay's test files. > > > Kind regards, > Paul Vinkenoog Jeremias Maerki
