Zoom parameter implemented "upside-down"

[Snuffleupagus]

According to the open parameter specification, link, the zoom parameter should be implemented as: zoom=scale,left,top, with the interpretation:

Scroll values left and top are in a coordinate system where 0,0 represents the top left corner of the visible page, regardless of document rotation.

This is not the case in pdf.js, which is a problem if you try opening the following: http://mozilla.github.io/pdf.js/web/viewer.html#page=2&zoom=auto,0,0

• Expected result: The document should open at the top of page 2, as it does with Adobe Reader.
• What actually happens: The document is scrolled down to the top of page 3.

The problem seems to be that in pdf.js the origin in the coordinate system (the one that is exposed to the user) is placed at the bottom left corner. From what I've gathered, pdf.js internally uses a coordinate system placed at the top left corner of the page, so I don't know why it's not working. I'm not that familiar with this part of the codebase, but could the issue be here: https://github.com/mozilla/pdf.js/blob/master/src/util.js#L390

This issue might be related to issues involving links pointing to the wrong place in PDFs, e.g. #2814, #2401, #2151, since all those files contains links that also applies a rescaling to "page-fit". I'm guessing that what happens is that the zoom is set to zoom=page-fit,0,0, which clearly isn't working.

[gigaherz]

I just checked, to get the TOP of page 2, you have to specify http://mozilla.github.com/pdf.js/web/viewer.html#page=2&zoom=page-fit,0,792

While the middle of the page is http://mozilla.github.com/pdf.js/web/viewer.html#page=2&zoom=page-fit,0,430

It does appear to use a coordinate system where 0,0 is bottom-left, at least with this one PDF.

[Snuffleupagus]

I just checked, to get the TOP of page 2, you have to specify http://mozilla.github.com/pdf.js/web/viewer.html#page=2&zoom=page-fit,0,792

@gigaherz I know that, but I don't think that this is the right behaviour.

It does appear to use a coordinate system where 0,0 is bottom-left, at least with this one PDF.

It's the same with every PDF I've ever opened with pdf.js

[gigaherz]

I was just confirming it. I never read the specs so I don't know if it's right or not.

[yurydelendik]

Was that fixed by #2872?

[gigaherz]

Looks like it. @Snuffleupagus ?

[Snuffleupagus]

I don't think so, since #page=2&zoom=auto,0,0 still won't take you to the top of page number two.

[gigaherz]

Oh right, sorry, this is the top of page 3 I saw, not 2.

[timvandermeij]

Is this still an issue?

[Snuffleupagus]

@timvandermeij This behaviour hasn't changed, please try:

This is not the case in pdf.js, which is a problem if you try opening the following: http://mozilla.github.io/pdf.js/web/viewer.html#page=2&zoom=auto,0,0

• Expected result: The document should open at the top of page 2, as it does with Adobe Reader.
• What actually happens: The document is scrolled down to the top of page 3.

Whether this is a serious usability issue is debatable, but the issue still remains.

[timvandermeij]

Hm, I see. Interesting bug though. Any idea where this is handled in the code base?

[jasonstanden]

18 month bump, but it seems this issue is still open. The inconsistency with this and Adobe Reader is a frustration as I am unable to link to certain position in a PDF via zoom parameter due to differing results depending on if the user has pdf.js handling their PDFs or Adobe plugin.

If this could be updated to be consistent with Adobe Reader it would be very helpful.

[Snuffleupagus]

The issue seems to be that PDF files (internally) places the origin at the lower left corner of pages. (At least that's how it appears after a quick look in the specification, and a look at the typical format used in internal destinations.) We simply expose this coordinate system to the user, which should explain the difference compared to Adobe Reader. I've tried switching this around (only) in the user interface of the viewer, and initial testing indicates that this might actually work out. But before I consider submitting a pull request, I need to test it a lot more thoroughly. I also need to try and refactor my patch somewhat, since I'm not too happy about the way that this interacts with the existing code.

Provided that it all actually works out, I'm hoping to have a patch ready next week.

[jasonstanden]

Very good news. Hopefully you can get it working. Thanks for looking into it.

[vipulvkp]

@Snuffleupagus : Hi we tried solving this by replaced zoom parameter from (75,0,0) to (75) . This solution obviously works , but the problem is it works for some documents and for some documents it still shows the old feature of spilling over to next page.

Eg 1:

/show_pdf/123.pdf#page=2&zoom=75 ->goes to page 2 . Works well.

/show_pdf/456.pdf#page=2&zoom=75 ->goes to page 3 !!!! If I remove zoom parameter, it redirects fine to page 2.

So can u please tell why this happening . For one pdf it works well, but for some other pdf it still shows the same old behavior.

Are there any other factors related to pdf document that we should take care of???

Thanks

[vipulvkp]

Hi guys,

It has been more than one year now and we are still experiencing wierd behaviours of this plugin with respect to zoom parameters.

Just have a look at my previous comment on this same page. I sat for hours to debug but could not find the reason as to why it is happening like this.

@Snuffleupagus : Please let us know the way forward for handling this issue.

Thanks

[jraygauthier]

The top of the page of the spec for the zoom parameter by adobe (for pdf.js users)

For any other users, the preceding will show the bottom of the page.

The top of the page of the spec for the zoom parameter by adobe (for any other users: chrome, explorer or acrobat)

For pdf.js users, the preceding will show the bottom of the page.

Note that both cases won't reach the same bottom which would mean that there is an issue with the scale of the vertical component of the coordinate system as well...

[markmatney]

I've been looking into this issue a bit, and I agree with @Snuffleupagus 's comment. Currently, PDF JS interprets the zoom parameter value of PDF URL fragments according to the definition of the "user space" coordinate system in the PDF Reference (1.7):

The positive x axis extends horizontally to the right and the positive y axis vertically upward, as in standard mathematical practice (subject to alteration by the Rotate entry in the page dictionary).

It should instead be using the coordinate system defined by the open parameters document:

Scroll values left and top are in a coordinate system where 0,0 represents the top left corner of the visible page, regardless of document rotation.

Before the code in web/pdf_link_service.js calls BaseViewer.scrollPageIntoView, there should be a transformation from the "open parameters" coordinate system to the "user space" coordinate system.