After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 517455 - page links (found in TOC and outlines) with Beamer PDFs are off by one
page links (found in TOC and outlines) with Beamer PDFs are off by one
Status: RESOLVED NOTABUG
Product: evince
Classification: Core
Component: PDF
2.21.x
Other All
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-19 15:13 UTC by Rémi Cardona
Modified: 2008-05-25 18:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Rémi Cardona 2008-02-19 15:13:44 UTC
Please describe the problem:
Beamer produced pdf can have TOC/outlines. Such outlines have links for each section which goes to the appropriate page/slide.

Steps to reproduce:
1. http://latex-beamer.sourceforge.net/beamerexample1.pdf
2. go manually to page 4 (the full outline)
3. click on the "Palindromes" subsection
4. evince will display page 32 instead of 31 *but* the current page displayed in the textbox in the toolbar will say 31

Actual results:
Evince displays page 32 (and it's misaligned)

Expected results:
Evince should display page 31

Does this happen every time?
Everytime, with all beamer produced pdf I could find or make myself

Other information:
Bug also exists in 2.20.x
Comment 1 Rémi Cardona 2008-02-19 15:16:04 UTC
Forgot to mention :
- evince 2.21.90
- poppler and poppler-bindings 0.6.3
- Gentoo unstable (reproducible on both x86 and amd64)
Comment 2 Carlos Garcia Campos 2008-02-19 17:40:35 UTC
I'd say it's a duplicate of bug #460658, but it should be fixed in 2.21.90. It works for me. 
Comment 3 Rémi Cardona 2008-02-20 07:51:35 UTC
Indeed, the document in bug #460658 does seem to work fine (at least the TOC on page 15). But not the one I linked from the beamer project page.

I can also confirm that acroread seems to be doing the right thing. I don't have any other pdf viewers to compare with.
Comment 4 Rémi Cardona 2008-04-08 21:30:04 UTC
Ahha! I just realized that the bug only appears when evince is in the "continuous" mode. In "page" mode, everything works fine.

Can you reproduce that way?

(btw, I'm now using evince 2.22.1.1 and it still behaves that way)
Comment 5 Carlos Garcia Campos 2008-04-15 13:29:25 UTC
Yes, it's reproducible for me. Confirming.
Comment 6 Rémi Cardona 2008-05-23 12:15:14 UTC
Hi Carlos

Any updates on the bug? Are there any patches I could try?

Thanks
Comment 7 Carlos Garcia Campos 2008-05-25 18:28:35 UTC
Ok, it's not definitely a bug, but a problem in the document itself. Look at the link in the PDF:

242 0 obj <<
/D [1219 0 R /XYZ 334.488 0 null]
>> endobj

This means that we should jump to page referenced by object 1219 (page 31), moving to the coord left: 334,448 top: 0 leaving the zoom factor unchanged. Top = 0 actually means to jump to: page_height - 0 = page_height, and that's exactly what is happening, we are jumping to the end of page 31. Acroread does the same indeed.