You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jay Bryant <ja...@bryantcs.com> on 2007/04/11 05:03:25 UTC
Change to support named destination and test files
Hi, folks,
I sorted the destinationList in PDFDocument. To do so, I used
Collections.sort(), which required creating a comparator class.
It works!
You can see the results at http://www.bryantcs.com/fop/test/fruit-link.pdf,
which contains four links to http://www.bryantcs.com/fop/test/fruits.pdf. At
least for me (using Firefox), all the links open where they should.
Jay Bryant
Bryant Communication Services
Re: Change to support named destination and test files
Posted by Jay Bryant <ja...@bryantcs.com>.
> Hello !!
>
> First, thanks for the work, but I have 2 remarks:
>
> 1/ I have done a little test with 2 pdf documents that have externals
> links
> between them. These documents are xml docbook files and are generated with
> saxon to obtain xsl-fo then with the last fop-trunk (527408) for pdf. When
> I
> click on a external link on the first pdf, the second pdf is open by
> firefox
> on the first page but it doesn't go on the good page where the external
> link
> is.
>
> 2/ when I repeat this test with the 42067 patch, I get the same result as
> case 1.
>
> remark : in case 2, bookmarks work fine but in case 1, it goes on the top
> of
> the page.
>
> Did I miss something ?
>
> Regards,
>
> Hugues Leonardi.
>
Hi, Hugues,
Thanks for looking at the patch for us - all testing helps.
I am also developing a DocBook-based system for one of my clients, and it
was that client's needs that drove the effort for named destinations. That
client is just about to post a bunch of books produced with their DocBook
system to their web site, and that will be the acid test, I guess.
Eventually, we'll discover the reasons behind the odd behavior and find a
fix for it. In the meantime, please bear with us.
Thanks.
Jay Bryant
Bryant Communication Services
Re: Change to support named destination and test files
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 14.04.2007 01:36:12 Paul Vinkenoog wrote:
> Hello Jeremias,
>
> > 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....
>
> If I build with the current (unmodified) fop-trunk, Adobe Acrobat 5.0
> lists the destinations alright. Which version did you use?
Forgot to add: That test was done with Acrobat 7.0.7.
> Testing your dest.pdf and nbackup.pdf online, I get the same results
> as before. With Firefox: good most of the time, but sometimes wrong
> (landing on top of file instead of the page where the target is).
> With MSIE: wrong most of the time.
>
> If I download the files to my computer and test them there, it often
> goes wrong (note that on my computer, if I click on a URI link in the
> PDF, MSIE is launched, even though Firefox is my default browser).
>
> I can't test your GoToR links locally, because GoToR generation is
> broken in fop-trunk (they work online though, because they are broken
> in such a way that they form a correct URL...)
>
> So, all in all, after your modifications I get the same results (good
> and bad) as before. Still I think they're an improvement, because
> there's less unnecessary indirection.
>
> (I also think that where it goes wrong, the browsers are at fault,
> especially MSIE, and not the destinations code).
>
>
> Regards,
> Paul Vinkenoog
Jeremias Maerki
Re: Change to support named destination and test files
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Paul, Simon, Hugues,
thanks for your feedback. Looks like that wasn't it. But now we know
that it's not only FOP contributing to the problems (not that this is
good news). I'll go over it again, later.
On 14.04.2007 01:36:12 Paul Vinkenoog wrote:
> Hello Jeremias,
>
> > 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....
>
> If I build with the current (unmodified) fop-trunk, Adobe Acrobat 5.0
> lists the destinations alright. Which version did you use?
>
> Testing your dest.pdf and nbackup.pdf online, I get the same results
> as before. With Firefox: good most of the time, but sometimes wrong
> (landing on top of file instead of the page where the target is).
> With MSIE: wrong most of the time.
>
> If I download the files to my computer and test them there, it often
> goes wrong (note that on my computer, if I click on a URI link in the
> PDF, MSIE is launched, even though Firefox is my default browser).
>
> I can't test your GoToR links locally, because GoToR generation is
> broken in fop-trunk (they work online though, because they are broken
> in such a way that they form a correct URL...)
>
> So, all in all, after your modifications I get the same results (good
> and bad) as before. Still I think they're an improvement, because
> there's less unnecessary indirection.
>
> (I also think that where it goes wrong, the browsers are at fault,
> especially MSIE, and not the destinations code).
>
>
> Regards,
> Paul Vinkenoog
Jeremias Maerki
Re: Change to support named destination and test files
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Fri, Apr 13, 2007 at 05:38:47PM +0200, Jeremias Maerki wrote:
> Can somebody please test the files I deposited here?
> http://people.apache.org/~jeremias/fop/dest-test/
pv: GoToR: xpdf shows 'nbackup.pdf' and lands on the correct destination
adobe reader 7.0 lands on the correct destination
URI: xpdf is not able to handle this relative URL
adobe reader 7.0 treats this correctly as a file URL, launches the browser, which launches xpdf, which lands on the first page
jm: GoToR: xpdf does nothing, its GUI is unresponsive for a while
adobe reader 7.0 reports an error: The specified file nbackup.pdf#dest=nbackup-dochist does not exist
URI: xpdf is not able to handle this relative URL
adobe reader 7.0 treats this correctly as a file URL, launches the browser, which launches xpdf, which lands on the first page
pdfedit has an error message which may be related: 3:KERNEL:cpage.cc:collectAnnotations:348: Unable to get Annots array - message= not found in
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hello Jeremias,
> 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....
If I build with the current (unmodified) fop-trunk, Adobe Acrobat 5.0
lists the destinations alright. Which version did you use?
Testing your dest.pdf and nbackup.pdf online, I get the same results
as before. With Firefox: good most of the time, but sometimes wrong
(landing on top of file instead of the page where the target is).
With MSIE: wrong most of the time.
If I download the files to my computer and test them there, it often
goes wrong (note that on my computer, if I click on a URI link in the
PDF, MSIE is launched, even though Firefox is my default browser).
I can't test your GoToR links locally, because GoToR generation is
broken in fop-trunk (they work online though, because they are broken
in such a way that they form a correct URL...)
So, all in all, after your modifications I get the same results (good
and bad) as before. Still I think they're an improvement, because
there's less unnecessary indirection.
(I also think that where it goes wrong, the browsers are at fault,
especially MSIE, and not the destinations code).
Regards,
Paul Vinkenoog
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hugues Leonardi wrote:
>
>
> Hello Jeremias,
> Here are the result of the test of your files:
> my softwares are : firefox 2.0.0.3, acrobat reader 8 and windows XP pro
> SP2.
> 1/ test on line:
> a- Gotor links are not working well: first, there is an acrobat plug-in
> message "/!\ operation is not allowed", then, when I click on OK to
> continue, the nbackup.pdf is opened at the good page but always at the top
> of the page, not at the level of the link in the page.
>
> b- URI links open nbackup.pdf correctly at the good page but always at
> the top of the page, not at the level of the link in the page.
>
> 2/ test with downloaded files:
> a/ Gotor links are not working at all: Acrobat reader shows an error
> message and that's all.
> b/ - if firefox is not opened, when I click on an URI link, firefox is
> opened and a blank page is shown
> - if firefox is first opened, when I click on an URI link,
> nbackup.pdf is opened in a firefox notebook at the good page but always at
> the top of the page.
>
> With Paul Vinkenoog files, both in line and downloaded tests are good for
> me: links are opened at the good page and at the good level in the page.
>
> Regards.
>
> Hugues Leonardi
>
>
Jeremias Maerki-2 wrote:
>
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9997828
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Change to support named destination and test files
Posted by Jay Bryant <ja...@bryantcs.com>.
> 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
Hi, Paul,
Thanks for the additional testing and for the code review.
My only guess about the odd opening behavior is that different browsers do
different things, though that still doesn't explain the inconsistency within
the same browser.
I will also try to do some more testing, but it won't be until the weekend.
Two of my clients are keeping me busy this week. Also, I just finished
building a new computer, so now I need to put the OS and apps on the thing.
Jay Bryant
Bryant Communication Services
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
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
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
PS:
> - 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 fox:destinations in the target file in alphabetical
order and rebuilding the PDF, the above still holds. So whatever the
cause, it's not a sorting problem.
Regz,
Paul
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hugues Leonardi wrote:
>
> Hello Paul,
>
> Thanks a lot for your help. I will try to build a new fo file as you told.
>
> Regards.
>
> Hugues Leonardi
>
>
Paul Vinkenoog wrote:
>
> Hello Hugues,
>
>>> All the external links open the second pdf at the first page in
>>> acrobat reader. I don't think it is the accent aigu in the id. My
>>> xsl-fo and the pdf files are here :
>>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>>> External links have been written in red in the file named
>>> guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40...
>
> The reason it doesn't work is that there are no destinations defined
> in the target document. This doesn't happen automatically; you have to
> declare them in guide-reference.xml.fo like this:
>
> <fox:destination internal-destination="GDeLTK"/>
> <fox:destination internal-destination="execfeuillestyle"/>
> <fox:destination internal-destination="Unites"/>
> <fox:destination
> internal-destination="DocumentAvecPoliceParticuliC(re"/>
> <fox:destination internal-destination="ConfigurerFeuilleStyle"/>
> <fox:destination internal-destination="liensexternes"/>
>
> The order is unimportant, and they don't have to be all together
> either. Just make sure that each <fox:destination> is the direct child
> of a <fo:block>.
>
> Also declare this namespace in guide-reference.xml.fo:
>
> xmlns:fox="http://xmlgraphics.apache.org/fop/extensions"
>
> Then if you rebuild guide-reference, the named destinations will be
> included in the PDF. There's no need to rebuild guide-demarrage.
>
>
> BTW: your <fo:bookmark-tree>s currently contain this declaration:
> xmlns:fox="http://xml.apache.org/fop/extensions"
> This is not necessary, because fo:bookmarks are part of the standard.
> Also, that URL is outdated, iirc.
>
>
> Hope this helps,
> Paul Vinkenoog
>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9987401
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hello Hugues,
>> It works fine but on acrobat reader 7.0x, if I click on an external
>> link: - if the link that points to an element which is between the
>> top of the page and the middle of the page, it's OK, the element is
>> shown at the top of the acrobat reader window
>> - if the link that points to an element which is between the bottom
>> of the page and the middle of the page, the element is not shown at
>> the top of the window.
>> It's the same thing with bookmarks or internals links.
>>
>> On acrobat reader 8, all is OK.
This *may* have to do with the configuration of both readers. Unless
the view is "continuous", Adobe wil never scroll in such a way that
you see the "gap" between two pages. So if the target is roughly on
the bottom half of the page (depending on magnification, window size
etc.) it can't be shown at the top of the window unless Continuous is
active. Otherwise, the bottom of the page will be aligned with the
bottom of the window and the link target will be "somewhere" on the
visible part of the page.
Kind regards,
Paul Vinkenoog
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hugues Leonardi wrote:
>
> Hello Paul,
> I just want to do a little feedback about my tests.
> I have done modifications on my little application which permit now to
> build correctly pdf files with external links.
> It works fine but on acrobat reader 7.0x, if I click on an external link:
> - if the link that points to an element which is between the top of the
> page and the middle of the page, it's OK, the element is shown at the top
> of the acrobat reader window
> - if the link that points to an element which is between the bottom of the
> page and the middle of the page, the element is not shown at the top of
> the window.
> It's the same thing with bookmarks or internals links.
>
> On acrobat reader 8, all is OK.
>
> Best regards
>
> Hugues Leonardi
>
>
Paul Vinkenoog wrote:
>
> Hello Hugues,
>
>>> All the external links open the second pdf at the first page in
>>> acrobat reader. I don't think it is the accent aigu in the id. My
>>> xsl-fo and the pdf files are here :
>>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>>> External links have been written in red in the file named
>>> guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40...
>
> The reason it doesn't work is that there are no destinations defined
> in the target document. This doesn't happen automatically; you have to
> declare them in guide-reference.xml.fo like this:
>
> <fox:destination internal-destination="GDeLTK"/>
> <fox:destination internal-destination="execfeuillestyle"/>
> <fox:destination internal-destination="Unites"/>
> <fox:destination
> internal-destination="DocumentAvecPoliceParticuliC(re"/>
> <fox:destination internal-destination="ConfigurerFeuilleStyle"/>
> <fox:destination internal-destination="liensexternes"/>
>
> The order is unimportant, and they don't have to be all together
> either. Just make sure that each <fox:destination> is the direct child
> of a <fo:block>.
>
> Also declare this namespace in guide-reference.xml.fo:
>
> xmlns:fox="http://xmlgraphics.apache.org/fop/extensions"
>
> Then if you rebuild guide-reference, the named destinations will be
> included in the PDF. There's no need to rebuild guide-demarrage.
>
>
> BTW: your <fo:bookmark-tree>s currently contain this declaration:
> xmlns:fox="http://xml.apache.org/fop/extensions"
> This is not necessary, because fo:bookmarks are part of the standard.
> Also, that URL is outdated, iirc.
>
>
> Hope this helps,
> Paul Vinkenoog
>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a10233817
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hello Hugues,
>> All the external links open the second pdf at the first page in
>> acrobat reader. I don't think it is the accent aigu in the id. My
>> xsl-fo and the pdf files are here :
>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
>> External links have been written in red in the file named
>> guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40...
The reason it doesn't work is that there are no destinations defined
in the target document. This doesn't happen automatically; you have to
declare them in guide-reference.xml.fo like this:
<fox:destination internal-destination="GDeLTK"/>
<fox:destination internal-destination="execfeuillestyle"/>
<fox:destination internal-destination="Unites"/>
<fox:destination internal-destination="DocumentAvecPoliceParticuliC(re"/>
<fox:destination internal-destination="ConfigurerFeuilleStyle"/>
<fox:destination internal-destination="liensexternes"/>
The order is unimportant, and they don't have to be all together
either. Just make sure that each <fox:destination> is the direct child
of a <fo:block>.
Also declare this namespace in guide-reference.xml.fo:
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions"
Then if you rebuild guide-reference, the named destinations will be
included in the PDF. There's no need to rebuild guide-demarrage.
BTW: your <fo:bookmark-tree>s currently contain this declaration:
xmlns:fox="http://xml.apache.org/fop/extensions"
This is not necessary, because fo:bookmarks are part of the standard.
Also, that URL is outdated, iirc.
Hope this helps,
Paul Vinkenoog
Re: Change to support named destination and test files
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Apr 12, 2007 at 12:49:57AM -0700, HLeonardi wrote:
>
>
> Hugues Leonardi wrote:
> >
> > Hello Paul,
> >
> > All the external links open the second pdf at the first page in acrobat
> > reader. I don't think it is the accent aigu in the id. My xsl-fo and the
> > pdf files are here :
> > http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
> > http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
> > External links have been written in red in the file named
> > guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40...
I read these documents in xpdf on a linux system, and I get the
same results: the links from the demarrage document open the reference
document on the first page. xpdf shows the value of the links as
"../guide-reference/guide-reference.xml.pdf", suggesting that the
named destinations did not make it into the PDF document.
I read Paul's documents in xpdf as well, and the GoToR links worked
perfectly. The URI links did not, but that is due to the fact that
xpdf does not know the base URI. BTW, one of the documents is called
dest.pdf, not dests.pdf.
Hugues, your GDeLTK application looks interesting. I will take a
closer look at it. It is a bit of a problem that it is all in French,
but I can also see that as a challenge to refresh my French.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hugues Leonardi wrote:
>
> Hello Paul,
>
> All the external links open the second pdf at the first page in acrobat
> reader. I don't think it is the accent aigu in the id. My xsl-fo and the
> pdf files are here :
> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
> http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation
> External links have been written in red in the file named
> guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40...
>
> Regards.
>
> Hugues Leonardi
>
>
>
> Paul Vinkenoog wrote:
>>
>> Hello Hugues,
>>
>>> I have modified xsl DocBook stylesheet to generate the correct url
>>> for external-destination and I have done a little test:
>>
>> Just a note: both forms are correct; it's just how you prefer the
>> target to be opened.
>>
>>> in my xsl-fo, anywhere there is an external link, it look like this:
>>> <fo:basic-link color="red"
>>> external-destination="../guide-reference/guide-reference.xml.pdf#dest=Unités"
>>> show-destination="new">Annexe E: « Unités de mesure et mention des
>>> couleurs » dans le document intitulé <fo:inline
>>> font-style="italic">Manuel de référence de GDeLTK</fo:inline>
>>> </fo:basic-link>
>>>
>>> note : my pdf is produced with the latest fop-trunk and I apply
>>> 42067 patch.
>>
>> This is true for both the target PDF and the referring PDF?
>>
>>> I confirm the document which contain the external link is now opened
>>> with adobe acrobat reader (8, under windows XP pro), but only at the
>>> first page, not at the page where the external link is.
>>
>> A wild guess: maybe the accent aigu in the id messes up the sorting of
>> the names. Does the target PDF contain more named destinations? Maybe
>> you can put it online somewhere (or another one that goes wrong) so
>> other people can try it out, as well as look inside the PDF.
>>
>>
>> Kind regards,
>> Paul Vinkenoog
>>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9954673
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hello Hugues,
> I have modified xsl DocBook stylesheet to generate the correct url
> for external-destination and I have done a little test:
Just a note: both forms are correct; it's just how you prefer the
target to be opened.
> in my xsl-fo, anywhere there is an external link, it look like this:
> <fo:basic-link color="red"
> external-destination="../guide-reference/guide-reference.xml.pdf#dest=Unités"
> show-destination="new">Annexe E: « Unités de mesure et mention des
> couleurs » dans le document intitulé <fo:inline
> font-style="italic">Manuel de référence de GDeLTK</fo:inline>
> </fo:basic-link>
>
> note : my pdf is produced with the latest fop-trunk and I apply
> 42067 patch.
This is true for both the target PDF and the referring PDF?
> I confirm the document which contain the external link is now opened
> with adobe acrobat reader (8, under windows XP pro), but only at the
> first page, not at the page where the external link is.
A wild guess: maybe the accent aigu in the id messes up the sorting of
the names. Does the target PDF contain more named destinations? Maybe
you can put it online somewhere (or another one that goes wrong) so
other people can try it out, as well as look inside the PDF.
Kind regards,
Paul Vinkenoog
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hello Paul,
Thanks for the response. Effectively, I use external destination such as you
describe (external-destination="nbackup.pdf#nbackup-dochist").
I have taken a look about
external-destination="nbackup.pdf#dest=nbackup-dochist":
I have modified xsl DocBook stylesheet to generate the correct url for
external-destination and I have done a little test:
- in my xsl-fo, anywhere there is an external link, it look like this:
<fo:basic-link color="red"
external-destination="../guide-reference/guide-reference.xml.pdf#dest=Unités"
show-destination="new">Annexe E: « Unités de mesure et mention des couleurs
» dans le document intitulé <fo:inline font-style="italic">Manuel de
référence de GDeLTK</fo:inline>
</fo:basic-link>
note : my pdf is produced with the latest fop-trunk and I apply 42067 patch.
I confirm the document which contain the external link is now opened with
adobe acrobat reader (8, under windows XP pro), but only at the first page,
not at the page where the external link is.
Best regards.
Hugues Leonardi.
Paul Vinkenoog wrote:
>
> Hello Hugues,
>
>> 1/ I have done a little test with 2 pdf documents that have
>> externals links between them. These documents are xml docbook files
>> and are generated with saxon to obtain xsl-fo then with the last
>> fop-trunk (527408) for pdf. When I click on a external link on the
>> first pdf, the second pdf is open by firefox on the first page but
>> it doesn't go on the good page where the external link is.
>
> After applying Jay's latest commits, I've set up a test case with 5
> named destinations (declared in non-alphabetical order) and I get
> inconsistent results.
>
> - 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
>
> - When I link to them as PDF destinations, like this:
>
> external-destination="nbackup.pdf#dest=nbackup-dochist"
>
> the document is opened in Adobe and always at the right location.
> (Note: this only works if you have applied patch 42067, which you
> have.)
>
>
> Looking inside the PDF Dests object, I see that
>
> a) the top-level /Limits are OK: they show the alphabetically first
> and last elements.
>
> b) the /Kids are sorted alphabetically on destination name.
>
> So I wonder: might it be the browsers that are screwing up here?
> Notice the plural: although Firefox is my default browser, PDF URLs
> are opened in MSIE.
>
>
> Kind regards,
> Paul Vinkenoog
>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9949540
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hello Hugues,
> 1/ I have done a little test with 2 pdf documents that have
> externals links between them. These documents are xml docbook files
> and are generated with saxon to obtain xsl-fo then with the last
> fop-trunk (527408) for pdf. When I click on a external link on the
> first pdf, the second pdf is open by firefox on the first page but
> it doesn't go on the good page where the external link is.
After applying Jay's latest commits, I've set up a test case with 5
named destinations (declared in non-alphabetical order) and I get
inconsistent results.
- 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
- When I link to them as PDF destinations, like this:
external-destination="nbackup.pdf#dest=nbackup-dochist"
the document is opened in Adobe and always at the right location.
(Note: this only works if you have applied patch 42067, which you
have.)
Looking inside the PDF Dests object, I see that
a) the top-level /Limits are OK: they show the alphabetically first
and last elements.
b) the /Kids are sorted alphabetically on destination name.
So I wonder: might it be the browsers that are screwing up here?
Notice the plural: although Firefox is my default browser, PDF URLs
are opened in MSIE.
Kind regards,
Paul Vinkenoog
Re: Change to support named destination and test files
Posted by HLeonardi <le...@free.fr>.
Hello !!
First, thanks for the work, but I have 2 remarks:
1/ I have done a little test with 2 pdf documents that have externals links
between them. These documents are xml docbook files and are generated with
saxon to obtain xsl-fo then with the last fop-trunk (527408) for pdf. When I
click on a external link on the first pdf, the second pdf is open by firefox
on the first page but it doesn't go on the good page where the external link
is.
2/ when I repeat this test with the 42067 patch, I get the same result as
case 1.
remark : in case 2, bookmarks work fine but in case 1, it goes on the top of
the page.
Did I miss something ?
Regards,
Hugues Leonardi.
Jay Bryant wrote:
>
> Hi, folks,
>
> I sorted the destinationList in PDFDocument. To do so, I used
> Collections.sort(), which required creating a comparator class.
>
> It works!
>
> You can see the results at
> http://www.bryantcs.com/fop/test/fruit-link.pdf,
> which contains four links to http://www.bryantcs.com/fop/test/fruits.pdf.
> At
> least for me (using Firefox), all the links open where they should.
>
> Jay Bryant
> Bryant Communication Services
>
>
>
>
--
View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9935286
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Posted by Paul Vinkenoog <pa...@vinkenoog.nl>.
Hi Jay,
> I sorted the destinationList in PDFDocument. To do so, I used
> Collections.sort(), which required creating a comparator class.
>
> It works!
>
> You can see the results at
> http://www.bryantcs.com/fop/test/fruit-link.pdf, which contains four
> links to http://www.bryantcs.com/fop/test/fruits.pdf. At least for
> me (using Firefox), all the links open where they should.
Same here, if I use the links on your site. Also if I download both
PDFs to my computer the links keep working, no matter how many times I
try.
But as you can see in the other thread, it doesn't always work
perfectly. I have no idea what causes those inconsistent results but I
suspect it's on the browser side. Your code and the resulting PDF seem
100% alright.
BTW, I was wrong about the lexicographical ordering. It must be
asciibetical, and that's exactly what your comparator class does.
Greetings,
Paul Vinkenoog