New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes 'Go to...' or 'Outline' doesn't work #48

Closed
FrankEular opened this Issue Jun 1, 2014 · 13 comments

Comments

Projects
None yet
4 participants
@FrankEular

FrankEular commented Jun 1, 2014

It's a weird issue. Usually when I press 'Go to...' and type a number and press 'Go', it simply refreshes at the original page, not the page I inputted. I need to do twice or so to switch to a new page. The problem of 'Outline' is similar. When I choose a page in 'Outline', it stops at the original page. I need to do this many times to switch a page.

Android 4.1.2 (my Samsung phone) & Android 4.1.1 (my Samsung tab)
Document Viewer 2.5, installed from F-Droid.

@dartsman

This comment has been minimized.

dartsman commented Jul 2, 2014

Observed with the same symptoms. Doubt this app is maintained, though.

@dorgy

This comment has been minimized.

dorgy commented Jul 5, 2014

True....this is long problem.
They are work ...but you must select go gage or outline twice....
Ex: go 23 go 23.....

@tuxor1337 tuxor1337 added the bug label Nov 3, 2014

@tuxor1337

This comment has been minimized.

tuxor1337 commented Nov 3, 2014

Confirmed. Seems like the "goto" feature is broken.

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jan 29, 2015

Will be fixed, once mupdf is updated to the latest version. Use issue #51 to track the progress of the mupdf-update.

@tuxor1337 tuxor1337 closed this Jan 29, 2015

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jan 29, 2015

Just noticed, that this is still an issue. But it doesn't seem to be permanent?!

@tuxor1337 tuxor1337 reopened this Jan 29, 2015

@tuxor1337 tuxor1337 closed this in 542ed8e Feb 16, 2015

@FrankEular

This comment has been minimized.

FrankEular commented May 16, 2015

I found that in the latest version, it sometimes went to the wrong page
when clicking outline, but it's a minor bug since the offset is always
plus/minus 1.

On Mon, Feb 16, 2015 at 9:18 AM, tuxor1337 notifications@github.com wrote:

Closed #48 #48 via
542ed8e
542ed8e
.


Reply to this email directly or view it on GitHub
#48 (comment)
.

@tuxor1337

This comment has been minimized.

tuxor1337 commented May 17, 2015

@FrankEular I'm using this app on a daily basis and haven't had any such issues for a long time now. Can you explain how to reproduce this step by step?

@FrankEular

This comment has been minimized.

FrankEular commented Jun 21, 2015

Simply go through the outline and choose Chapter 1.
Maybe the problem is that the page of the chapter is DIFFERENT from
that of the first section of that chapter, just like:

Outline:

Chapter 1 <- page 8
1.1 xxx <- page 9

Click Chapter 1 then Document Viewer goes to page 9.

Sorry, the pdf file is too large to upload! Maybe I've pointed out the issue.

On 6/22/15, eular frank eular.frank@gmail.com wrote:

On 5/17/15, tuxor1337 notifications@github.com wrote:

@FrankEular I'm using this app on a daily basis and haven't had any such
issues for a long time now. Can you explain how to reproduce this step by
step?


Reply to this email directly or view it on GitHub:
#48 (comment)

Simply go through the outline and choose Chapter 1.
Maybe the problem is that the page of the chapter is DIFFERENT from
that of the first section of that chapter.

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jun 21, 2015

As long as there's only a single pdf that has this issue, I would suspect that the error lies in the pdf instead of this app. Have you compared with the behaviour of another pdf viewer? I won't reopen, as long as I'm not able to reproduce this.

@FrankEular

This comment has been minimized.

FrankEular commented Jun 23, 2015

I opened it on my laptop with evince under linux, there was no problem.

The pdf file could be downloaded here:
http://gen.lib.rus.ec/book/index.php?md5=D9D636FAC19541905640F56164C8DA8A

Check "Chapter 1" in outline, say.

CAUTION: It's a pirate, therefore should be used with restriction.

On 6/22/15, tuxor1337 notifications@github.com wrote:

As long as there's only a single pdf that has this issue, I would suspect
that the error lies in the pdf instead of this app. Have you compared with
the behaviour of another pdf viewer? I won't reopen, as long as I'm not able
to reproduce this.


Reply to this email directly or view it on GitHub:
#48 (comment)

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jun 23, 2015

That is indeed document specific. But it doesn't seem to be due to mupdf, since other pdf viewers that use mupdf don't suffer from this (tested with zathura). The targetRect of the link in the outlines is altered somewhere, because MuPdf gives the right offsets, but in the end the offsetY is wrong.

@tuxor1337 tuxor1337 reopened this Jun 23, 2015

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jun 23, 2015

The question is: what exactly is happening in normalizeLinkTargetRect what is the meaning of the flag 0x0F in line 61 of MuPdfDocument.java? Why is this flag set in the outline of the above pdf, but not in other pdfs with similar outline?

@tuxor1337

This comment has been minimized.

tuxor1337 commented Jun 23, 2015

The flags are all in mupdf's include/mupdf/fitz/link.h and apparently, with 0x0F we check for fz_link_flag_t_valid, fz_link_flag_l_valid, fz_link_flag_r_valid, fz_link_flag_b_valid even though we only handle the t and l values. Solution: Only check for 0x03. I think we can stick to ignoring the b and r parts because other pdf viewers do the same and noone seems to complain about that...

@tuxor1337 tuxor1337 closed this in 253a906 Jun 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment