New issue
Advanced search Search tips
Starred by 147 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Closed: Dec 13
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 Back to list
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
Labels: -Type-Bug -Area-Undefined Type-Feature Area-Internals Feature-Plugins
Comment 2 by Deleted ...@, Jan 19 2011
Comment 3 by Deleted ...@, Apr 21 2011
It's very important for us. We need "scrollbar", "toolbar" and "navpanes" parameters too. Thank's for help!
Labels: -Feature-Plugins Feature-PDF
Comment 5 by, Jul 5 2011
I am looking for the #page= parameter.
Yes view parameter
Comment 7 by Deleted ...@, Aug 15 2011
Is there any progress on this?  This is very important for a web application I am trying to develop.  It appears that Chrome completely ignores the URL open parameters for PDF documents. 
Comment 8 by, Aug 19 2011
This is ridiculous. I have an idea... lets take a feature that works the same way in every browser and remove it ! becuase..... umm... hmmmm..... 
Comment 9 Deleted
Comment 10 Deleted
Comment 11 by Deleted ...@, Sep 1 2011
That matter of Chrome PDF renderer not responding to PDF open parameters has a more important usability consequence. Please open the following in any other browser and you'll surely get the point:"organisation";

Of course, the fact that Adobe uses a hash as the (only possible) delimiter for the opening parameters might complicate things a bit, but it would be simple for the Chrome engine to parse the url and decide whether the hash is meant for a PDF or not.
Comment 12 by Deleted ...@, Dec 24 2011
It would appear that the page and zoom parameters are now supported, so why not others? I would vote for the search feature to be implemented the same as Adobe's functionality, as it would be very useful. Especially combining a search and page parameter.
+1 my code : 
<object name="PDF" data="fichiers/communique-presse.pdf#view=FitH&scrollbar=0" type="application/pdf" width="540" height="760"></object>

Work everywhere but not on my last version of chrome...
Comment 14 by Deleted ...@, Feb 27 2012
    <object id="objPDF" data="file.pdf#view=Fit&toolbar=0&statusbar=0&navpanes=0" type="application/pdf" width="700" height="540">

Not working either

Chrome version: 17.0.963.56 m

Comment 15 by Deleted ...@, Mar 14 2012
Here's a solution for the issue of Chrome ignoring ADOBE PDF Open Parameters.

In chrome://plugins, disable "Chrome PDF Viewer", enable "Adobe PDF Plug-in For Firefox and Netscape 10.1.2."
With this workaround, most of the open parameters I need will work properly. Just as importantly, after applying these changes, relative hyperlinks function properly.

I dearly wish that Google's Chrome team would eliminate what seems to be a flaw in the Chrome PDF viewer plug-in.
+1, It would be nice if at least "search=" parameter is added. Right now this breaks compatibility with a lot of inhouse apps, making matters even worse when integrating PDF documents into web applications.
Comment 17 by Deleted ...@, Jul 13 2012
Same question!!! please add parameter options to implement specified view of PDF in Chrome.
This is an important missing feature.
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.

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!
I'm still here too! 
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
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
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
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
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!
Sign in to add a comment