New issue
Advanced search Search tips

Issue 116297 link

Starred by 6 users

Issue metadata

Status: Fixed
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Sign in to add a comment

PDF rotation should maintain scroll position

Reported by, Feb 29 2012

Issue description

Version: 18.0.1025.33 beta
OS: Linux

What steps will reproduce the problem?
1. Load
2. Scroll down to the fourth page, which has "TABLE 1".
3. The table's sideways, so right-click and select "rotate clockwise"

What is the expected output? What do you see instead?

I'd like to see that page, rotated.
Instead, Chrome rotates every page [not what I wanted, but not too big a deal].  But then because the pages are shorter than they were, the page I wanted to look at is now off the top of the screen.  We should either just rotate the one page in place, or we should rotate them all, then scroll down to the page the user was looking at.

Please use labels and text to provide additional information.
Project Member

Comment 1 by, Mar 10 2013

Labels: -Area-Internals -Feature-PDF Cr-Internals Cr-Content-Plugins-PDF
Project Member

Comment 2 by, Apr 6 2013

Labels: Cr-Blink
Project Member

Comment 3 by, Apr 6 2013

Labels: -Cr-Content-Plugins-PDF Cr-Internals-Plugins-PDF

Comment 4 by, Jan 24 2014

ditto .. the viewer appears to refresh/reflow with at the same vertical depth - all it seems to need is for the viewer to refresh/reflow keeping the _page number_ constant instead.
yes, I agree, the scroll offset remain same after the flow, But we need to maintain the page number at which rotation have been done.
So we should make the reflow based on page number,so that same page come under the pluginsize rect and intersect with it properly.
can you some pointers to do reflow based on page number.
Labels: -Cr-Internals -Cr-Blink

Comment 7 by, Mar 30 2016

This bug has turned four a couple of weeks ago. Any chance this is easier to implement today than it was back then? Or is this in the works somewhere and should be merged?
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Available (was: Untriaged)
This recently annoyed me as well. The difference between now and 4 years ago is all the PDF code has been open sourced. So in theory anyone can dig into this if they'd like to.
PDFiumEngine::RotateClockwise() for anyone interested.

Let's say the PDF being viewed is 3 pages long, with page 1 and 3 being US Letter portrait and page 2 being US Letter landscape. If the current scroll position is at the 60% mark on page 2, it should remain at the 60% mark on page 2 after the rotation to landscape-portrait-landscape. Probably what is happening is the current position is set to some internal representation of: 11" + 0.6 * 8.5" = 16.1". After the rotation, it tries to maintain that, but 16.1" with the rotation is the ~70% mark on page 2. With bigger documents and positions further towards the end of the document, the amount of change can vary a lot more.
Status: Started (was: Available)
The actual math for comment 9 is a wee bit more complicated than in theory. For now, I'll just do the easy fix which is just to restore the current page number:

Will work on adjusting the scroll position later.
Status: Fixed (was: Started)
Going to call it a day on this bug. The fix should show up in version 54.0.2838.0 and newer. Bug 640081 is the follow up for better adjusting the scroll position.
BTW, individual page rotation is bug 715572.

Sign in to add a comment