New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 64309 link

Starred by 150 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Closed: Dec 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Blocked on:
issue 319910

Sign in to add a comment

Implement "PDF Open Parameters" in PDF Renderer

Reported by, Nov 24 2010

Issue description

Chrome Version       : 9.0.587.0 (Official Build 66374) dev
URLs (if applicable) :

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK (with Acrobat Reader plugin)
  Firefox 3.x: OK (with Acrobat Reader plugin)
       IE 7/8: OK (with Acrobat Reader plugin)

What steps will reproduce the problem?
1. Using an instance of Chrome that is configured to open PDFs with the Chrome PDF Renderer instead of Adobe Acrobat Reader, go to
2. In any browser using Acrobat Reader to open PDFs (including Chrome), because "#view=FitH" is appended to the URL, the PDF will initially be opened to fit horizontally.

What is the expected result?

The PDF open parameter appended to the URL should affect the way that the PDF opens.

The specification

What happens instead?

The PDF open parameter is ignored.

Please provide any additional information below. Attach a screenshot if

This is a more of a feature request than a bug. Acrobat Reader implements "PDF Open Parameters" as described in this specification:

For our web applications, the most important parameters are view, toolbar, and zoom. 

It would be awesome if the Chrome PDF Renderer implemented the specification, including when the PDF is embedded in the page (see

128 KB Download
Showing comments 19 - 118 of 118 Older
Project Member

Comment 19 by, Aug 10 2012

Labels: -Pri-2 Pri-3 Action-NeedsReview
Status: IceBox
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

Comment 20 by, Aug 10 2012

Status: Unconfirmed

Comment 21 by, Jan 15 2013

New year and the issue is still active? I've the Chrome up to date, but the view="FitH" still doesn't work.

Comment 22 by Deleted ...@, Feb 28 2013

Yeah, I'd really need view="Fit" badly!

Comment 23 by, Mar 8 2013

The page parameter is also not apply with the standard.
i.e. #page=2 will navigate to 3rd page in chrome. but it should navigate to page 2.
Chrome version: 24.0.1312.57 m.
Project Member

Comment 24 by, Mar 10 2013

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

Comment 25 by, Apr 6 2013

Labels: Cr-Blink
Project Member

Comment 26 by, Apr 6 2013

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

Comment 27 by Deleted ...@, Apr 19 2013

I need html code to force a link to a pdf to open in adobe.  If I am coding the link, and someone else is opening it, I do not have contact to tell them to disable it.  So is there any html code that can be added to an email or link, that will either force the pdf to only open in adobe, OR force google chrome pdf reader to jump to the correct page.  Right now it will open in google chrome pdf viewer, but it jumps to whatever page is coded +1

would open on page 3

Comment 28 Deleted

As an alternative to implementing this feature in full, whenever there are hash parameters, chrome could offer to open the PDF in the adobe's PDF viewer.
Labels: -Action-NeedsReview -Cr-Blink
Status: Assigned
The Chrome PDF viewer currently supports page= and nameddest=. The page= off-by-one error is bug 234128, which is also fixed.

It sounds like the original request is for view=. I'll put it in my queue.
adding search= and fith would also be great.
I filed the original request. Supporting "view=" would be awesome for our enterprise applications, and would allow us to migrate our customers from the Acrobat plugin to the Chrome PDF Renderer. "view=Fit", "view=FitH", and "view=FitV" are the three most important ones for our applications. "zoom=" is also important to us, but "view=" is more important to us. Thank you so much putting "view=" into your queue.
Michael, search= isn't defined in RFC 3778. Is there a newer RFC / specs page that defined it?
I agree that zoom= would also be helpful
I am not sure whether search= is in an RFC, but it's defined by Adobe in their reader:
While describing the PDF open parameters, the RFC 3778 states that the PDF open parameters are "currently defined in Adobe Technical Note 5428 [7]." The RFC links to the document, but that document is dead. A bit of internet searching brings it up here:

However, I think the link I provided in the comment directly above is more current.

Comment 37 by, Jun 29 2013

I'm desperately waiting for the VIEW option. Needing to click on the "fit/expand button" is always very frustrating. 

Comment 38 by, Jul 6 2013

For me, the page= off-by-one error is  (bug 234128?) is still a problem. And the view=Fit is actually view=FitH.
I also am still waiting for the VIEW option (i.e., #view=fitH, etc).

(I can't believe this has been waiting in the queue since 2010!)

I need to fit PDF documents I am opening to the width of an IFRAME.
Same as #39 here.
FitH would be very welcome.

Let's wait...
As I said, it's in the queue. Adding "me too" comments only slows me down to tell you to stop adding "me too" comments. :-P

Since view= sounds more popular, I'll try to do that, and then zoom= and search=. Please just star the bug if you feel it's important to you.
Could we have toolbar=0|1 as well?
Any updates on 'view' parameter being added?

Comment 44 Deleted

'view' parameter is very usefull.

Comment 46 by Deleted ...@, Nov 8 2013

I would like to see all of the PDF Open Parameters implemented, but I need the #page=pagenum one now.  Any updates?
Given the recent change to make the chrome PDF viewer default, I believe this issue to take on additional urgency:
Still nothing about a view= parameters? :-/
holy crap 4 years later and they still ignore it.
Adobe's PDF plugin has improved significantly in those 4 years.  I would be in favor of just ditching the built-in reader.

Comment 51 by, Apr 23 2014

Not everyone has Adobe Reader installed, and bundling it with chromium is probably not an option.
You put this one in your 'queue' around 11 months ago.  Is there any update?
WTB open parameters
Seriously folks, if you're going to default something in your browser then either A) give us a way to do what we need (FitH!) during development, or B) give us a way to disable yours from within HTML so we can use the Adobe reader. Disabling on our personal browser is ineffective for when we deploy a site with PDFs on it.

Comment 55 by Deleted ...@, Jun 23 2014

Apparently you're ignoring this request, at least please give a recommendation to developers

Comment 56 by Deleted ...@, Jul 2 2014

Any Update yet?
I would appreciate that too! 
At least "view=fit".
Any recommendations, updates or available shortcuts to get a solution?

Comment 58 by Deleted ...@, Jul 31 2014

need view parameter too ...
On option is to just not use their reader, and instead use pdf.js. Unfortunately, pdf.js is still a ways off from mainstream use.

Comment 60 by Deleted ...@, Aug 8 2014

Opening PDF-files optimized for fast web view e.g. with the parameter #page=500 open on the cover page and after loading the complete PDF Chrome jumps to the desired page number.

This is a huge disadvantage as the "optimized for web view" option enables to load the desired page first.
mikeg: re: comment 60 - please file a new bug for your problem.
Going on 4 years - Is anything going to be done or are you waiting for pdfjs for this?
Do a search for Cr:Internals-Plugins-PDF, there are 442 open issues right now. I'd bet there is 1 or at most 2 people working on this at Google. Doubtful this will ever get fixed.

Comment 64 by Deleted ...@, Aug 14 2014

Could really do with support for "view" and "toolbar" at least.
Project Member

Comment 65 by, Aug 19 2014

The following revision refers to this bug:

commit a6d93b2e41cd94d99c8b1fa3acde47082a8756de
Author: <>
Date: Tue Aug 19 09:52:16 2014

OOP PDF - Add support for "page" open pdf parameter

This patch adds support for "page" feature of open PDF
parameters in OOP PDF.

When page is used as an open PDF parameter, then PDF
should initially be loaded at the page specified by user.

BUG= 64309 

Review URL:

Cr-Commit-Position: refs/heads/master@{#290529}
git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Project Member

Comment 66 by, Aug 19 2014

r290529 | | 2014-08-19T09:52:16.253422Z

Changed paths:

OOP PDF - Add support for "page" open pdf parameter

This patch adds support for "page" feature of open PDF
parameters in OOP PDF.

When page is used as an open PDF parameter, then PDF
should initially be loaded at the page specified by user.

BUG= 64309 

Review URL:
Project Member

Comment 67 by, Aug 20 2014

The following revision refers to this bug:

commit f90b9a4c04c48c649dcde748173bb6a34fb97105
Author: <>
Date: Wed Aug 20 05:37:34 2014

PDF: Do more robust page number parsing in OOP plugin.

BUG= 64309 

Review URL:

Cr-Commit-Position: refs/heads/master@{#290770}
git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Project Member

Comment 68 by, Aug 20 2014

r290770 | | 2014-08-20T05:37:34.394982Z

Changed paths:

PDF: Do more robust page number parsing in OOP plugin.

BUG= 64309 

Review URL:
Project Member

Comment 69 by, Sep 5 2014

The following revision refers to this bug:

commit 27548ef89c672922f9c3888183c59d48ef2e7ae0
Author: n.bansal <>
Date: Fri Sep 05 17:25:37 2014

OOP PDF - Add support for "zoom" open pdf parameter

This patch adds support for zoom open pdf parameter. If user
opens pdf with zoom parameter in url then pdf should be opened
at zoom level mentioned by user.

BUG= 64309 ,  319910 

Review URL:

Cr-Commit-Position: refs/heads/master@{#293545}


Same as #58.

Comment 71 by Deleted ...@, Dec 12 2014

for those still wanting the #view=FitH functionality so far the best solution is to use the iframe tag instead of embed, and link the pdf directly into the src parameter.
...4 years to recognize a parameter? My God.

Comment 73 by Deleted ...@, Dec 30 2014

still needed

Comment 74 by Deleted ...@, Jan 4 2015

Any updates guys?
I used the iframe to get around the fit issue.  Unfortunately I am told our users should not be able to download the pdf.  Going to be hard to do when there is no way to disable toolbar.  First time I have ever seen IE work better than chrome.
Everyone should move to pdf.js, it's a better reader, with more features, and a far more active development team.
pdf.js is great, but... it returns an image of the page. Users can't copy part of the text, for instance to cite pasting it elsewhere.
@s.bargi... no it actually renders the entire PDF twice: once as an image quickly, and then a second time as an HTML DOM so text rendering works. Text selection does indeed work:

Note: text selection still kind of sucks (notice the flikering when you do it), but I'm working on a patch to fix that.

Comment 79 by, Feb 22 2015

Looks like this will never get done. Hehehe.
#79 bad news - #78 good news: i'll try pdf.js asap

Comment 81 by, Mar 16 2015

I need this feature as well. Since our PDF's contain sensitive information, we were forced to avoid the iframe route. Now we have no control over the size of the PDF without support for #view=

Comment 82 by Deleted ...@, May 15 2015

years pass, #view is still ignored in Chrome 
#view is nothing to implement comparing to massive Chrome updates ... still needed!
I need #search here... =/
Is it possible the  Issue 439114 :Re-design PDF viewer in Material ( will/can address this long-standing bug?  It looks like there's active development on that issue and I see similar names commenting. 

Comment 86 by, Jul 6 2015

FitH seems to have been resolved in May if I recall.

Comment 87 by, Feb 18 2016

Please add support for the page URL parameter.
Parameter search don't work in Chrome 57.0.2987.74 beta (64-bit), page parameter do work.

Open this (useful) PDF in Chrome and Firefox to see:

Comment 89 Deleted

#view=FitH is not working in Version 56.0.2924.87 (3rd March, 2017)

Or Opera 43.0.2442.1144 (PGO); Vivaldi 1.7.735.46

What's annoying is that the developer tool allows you to tweak the URL for the <object> tag, e.g. adding "#view=FitH", and see that this works great. Then you incorporate that into your code, but when the page displays that parameter has been ignored - you can see that the parameter is being included, but has no impact :-(

I tried in an Incognito Window, but it behaved in the same troublesome fashion.
Please add #search functionality.


Comment 92 by, Sep 12 2017

7 years so far. I'm 28 now (when bug reported I was 21, Trump wasn't president of United States, no one cared about global warming, Syria wasn't in war yet, David Bowie was alive) I wonder when this bug is fixed who's the president of United States, Am I still alive then? Is Roger Watters still alive? I wonder how world looks like when Chrome supports "view=FitW", maybe that day human being has travelled to Mars and Earth is not a place to live, Maybe sun isn't shining that day anymore. I hope they fix it before Sun turns off.

Comment 93 Deleted

T-4 days: matinee at the Restaurant at the End of the Universe
T-2 days: this bug gets fixed
T-1 days: evening show at the Restaurant at the End of the Universe
T-0 days: all entropy ceases; universe becomes changeless and utterly,
utterly dead for all eternity. Much like this bug report.
Hahahahaha priceless! Still waiting here too…

From: sass… via monorail []
Sent: Tuesday, September 12, 2017 05:22 PM
To: Dafna Ziegerman <>
Subject:  Issue 64309  in chromium: Implement "PDF Open Parameters" in PDF Renderer
Applaud your persistence, I gave up on this years ago!

Comment 98 by, Sep 13 2017

I'm still here too! 

Comment 100 by, Sep 13 2017

Here We Stand.
I was a 25-year-old intern learning how to code while working for a company straight out of college when I  subscribed to this bug.

I'm now a 32 senior web developer.
Issue 748852 has been merged into this issue.
Blocking: 542951
Blockedon: 319910
Project Member

Comment 109 by, Nov 21 2017

The following revision refers to this bug:

commit 50b18e0733f99646a418cd47c0995c4b73f15ea8
Author: Henrique Nakashima <>
Date: Tue Nov 21 23:29:57 2017

Implementing openparam view= in PDF viewer.

The values that are now accepted are:
- view=Fit
- view=FitH
- view=FitV

Bug:  64309 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I1072e3dc895e4c21cd9823adac13a8c3cf5dcd90
Commit-Queue: Henrique Nakashima <>
Reviewed-by: Demetrios Papadopoulos <>
Cr-Commit-Position: refs/heads/master@{#518441}

Project Member

Comment 110 by, Nov 23 2017

The following revision refers to this bug:

commit 6363f8da6aae63abedc87f60b629585f10bd8940
Author: Henrique Nakashima <>
Date: Thu Nov 23 19:14:51 2017

Openparams FitH and FitV in PDF viewer accept optional position.

Newly accepted values:
- view=FitH,[y]
- view=FitV,[x]

Bug:  64309 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I462365a12885d479b8255c6805ef9c568c0ec348
Commit-Queue: Henrique Nakashima <>
Reviewed-by: Demetrios Papadopoulos <>
Cr-Commit-Position: refs/heads/master@{#519002}

Blocking: -542951
Project Member

Comment 112 by, Dec 11 2017

The following revision refers to this bug:

commit 85fc58b39f733ada87d2ac144094e6f261d0e4cc
Author: Henrique Nakashima <>
Date: Mon Dec 11 21:53:42 2017

Fix zoom PDF param.

The "left" param was ignored because it was applied before the zoom,
and the page still fit in the window at 1x zoom. Scrolling on x was
non-op at this zoom level.

Bug:  319910 , 64309 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I7b476c018f9972f2b1e0075e933e6489f12e6974
Commit-Queue: Henrique Nakashima <>
Reviewed-by: dsinclair <>
Cr-Commit-Position: refs/heads/master@{#523223}

Status: Fixed (was: Assigned)
Out of the requests in this bug:

- view: implemented
- toolbar: implemented
- zoom: implemented
- scrollbar: not implemented, probably not something we want to either - we'd lock the user out of the rest of the document
- page: implemented
- nameddest: implemented
- search: filed bug 792647 to track separately
- navpanes: does not apply
- statusbar: does not apply

Finally closing as fixed.
Thank you!
This is excellent news, thanks so much!
Thanks team for implementing the Open Parameters.

I recenlty used the param 'toolbar=0' to hide the toolbar. It hides the top bar which has print and other icons.

However, the bottom-right bar, that has zoom in/out and fit to page buttons,  is still visible.

Is that a bug or as designed? I would want to hide that. Please see attached example. Thanks!

92.5 KB View Download

Comment 117 Deleted

Sorry for my English... 
It is possible access a specific file of a PDF file in an iframe using a link to, for example, file.pdf#page=15, but several links in the same page, for the same iframe, won't be able to access different pages of the same file. In otherwords, a single link access the page, but Chrome viewwer don't be able to actualize a page view of a pdf file with links in pdf open parameters. 

(obs.: pdf.js can do it!) 

Moreover, alternating a link to other file to the same iframe, the page address will open normally. It just don't work for the SAME file, in different links used in sequence. 

Showing comments 19 - 118 of 118 Older

Sign in to add a comment