Pdf.js: Feature: Two-page view

See also https://bugzilla.mozilla.org/show_bug.cgi?id=786602

About the 100% and page-fit, that is something Adobe Reader does and I agree that it would be nice to have it in PDF.js.

As for two-page view, I agree with that also.

+1

Any work towards this at all in the last ~4 years?

Since there is still some confusion on this, let me clarify this a bit. There has been a work-in-progress pull request for this, but the main problem was that it was _a lot_ of code because the viewer was not very modular at the time and we did not have integration tests for it. We still do not have integration tests for the viewer, so all testing of this must happen manually. It might not seem like it, but this is actually a difficult feature to support. What will happen when the pages are too wide? What will happen with different-sized pages?

This issue is open for a reason. We are still considering it as a useful feature, but someone has to find time to work on this. If anyone is willing to work on this, we first have to have some form of automated testing for the viewer, otherwise the risk of introduction regressions will be large.

+1

Please use GitHub's +1 reaction button instead of adding +1 comments here. Using the +1 reaction button allows us to filter on issues that have many +1's and thus allows us to prioritize issues in a better way.

ok. I used reaction button instead of comment. thanks

I'd like this so I could support the way that I actually think of books. Back before hypertext, there was a bit of railing at books for being "linear", some people even advocated getting to copies of a book so you could cut them apart and paste-up a giant poster of the entire book. Their was an early project called "Digital Shakespeare", that had all of his plays encoded in display postscript so you could "fly" over his work. This is a little too formless for me, so my convention is to think of sets of ten pages, grouped into 5 two-page spreads arranged like the spots on the five face of a die, e.g. thusly:

[0|1] [2|3]
`` [4|5]
[6|7] [8|9]

now there is a high level to this to take these and put them into set of hundreds.

The point is I might have a chance to do this and more with pdf.js, but I king of need two page display first.

👍

@timvandermeij Thanks for your update. I too am very much hoping to see a beta of this working!

What I have to do to make you add this feature? WHAT?

The next step is to help add automated integration testing: #6505

It's "a good beginner bug as this does not require much knowledge of the PDF.js codebase to work on. Perhaps contributors from other JS projects have experience with integration testing to help us out with this. The first step will be to choose and add the integration testing framework."

Is there any reason why this feature should be implemented in pdf.js itself? Implementing it in a reader app based on pdf.js is trivial and does not risk messing up the renderer. Let pdf.js handle single pages as it is used to, use two (or more, if needed) canvas elements in whatever geometry desired and fire off.

A simplistic demo took no more than a few minutes to write, based on the pdf.js previous/next example:

https://jsfiddle.net/Yetangitu/1egqfefu/4/

Navigate using the buttons or by clicking the left/right pages...

@tfer here's your 'Ludicrous mode' viewer: https://jsfiddle.net/Yetangitu/ht04sp3b/

(increase scale factor, display on big monitor, profit!)

As far as I can see there is no need for pds.js to support multi-page render, this can be handled adequately on a higher level.

@yurydelendik in what way is this solution confusing? I'm using it to build a PDF viewer for Nextcloud/Owncloud, it works fine.

in what way is this solution confusing?

It does not fit in our demo viewer.

https://jsfiddle.net/Yetangitu/1egqfefu/4/

@Yetangitu Writing custom viewer with dual-page display based on our examples is perfectly fine with me, but that it's not a PR we can accept. Shall we close this issue by referring that your proposed solution above addressed this issue? If not, please explain/show how your code can be applied to the demo viewer.

Please don't close this issue! Countless other issues have been opened and closed with a solution that doesn't address the central issue: PDFjs badly needs a built-in method for 2-page view. Many PDFs, such as journal articles, manuals, etc look fine in 1-page view. But ALL BOOKS, since Gutenberg, are designed to be viewed as L-R layouts. I'm using @Snuffleupagus's PR #3723 on a production site, and while it works well for now, it deserves to be developed further.

@yurydelendik it was not meant to be a complete solution, just as a hint to those people who have been looking for a spread-capable JS PDF viewer for many years. It could be integrated into the demo viewer but that'd take a bit of work. Since the viewer I'm building is meant to look and act (i.e. page horizontally, look as 'book-like' as feasible, etc) like the EPUB-viewer I made earlier it is quite different from the demo viewer so it is not a simple matter of patching the spread-capable bits in.

I do think that this type of functionality belongs in a viewer application, not in the basic PDF decoding/rendering library which is pdf.js, hence my reaction to this pdf.js issue.

I''l release the PDF-capable version of Reader in a few days for those who want to give the concept a try. Since Reader is a Nextcloud/Owncloud app, you'll need to have one of those handy somewhere...

@yurydelendik what is the link to your EPUB-viewer. It would be great if there was a simple JS library that could be included by default to help make it easier for folks to just view EPUB like they currently view PDFs. Maybe this is a new issue (or new project).

It's 2018 and this has been floating around for 7 years now. Whoa! Any updates/timelines on this yet?

The pull request above your comment implements this. Anyone is welcome to help us test it out to ensure that nothing breaks.

FYI, the Reader app for Nextcloud & Owncloud now supports PDF, including the 2-page (spread) mode I mentioned. It can be found on Github:

https://github.com/Yetangitu/owncloud-apps/tree/master/files_reader

and in the Nextcloud app repository:

https://apps.nextcloud.com/apps/files_reader

It will soon appear in the Owncloud repo as well.

The pull request above your comment implements this. Anyone is welcome to help us test it out to ensure that nothing breaks.

Eager to test, what do you need? Is there any binary blob or compiled SW we can test? Why not testing it via nightly, beta master cycle?

FYI, the Reader app for Nextcloud & Owncloud now supports PDF

Cool, now we just need to figure out how to run this as standalone viewer. Sumatra is also able to view 2 pages, but it has no subpixel rendering. FF has subpixel rendering, but no 2 page standard view. So currently there's no usable open source PDF viewer on windows :/

You can test it using the preview build at http://54.67.70.0:8877/5e5412c2765c9bd/web/viewer.html. Refer to #9208 for more information.

You can test it using the preview build at http://54.67.70.0:8877/5e5412c2765c9bd/web/viewer.html.

Amazing, thanks. In order to test it one has to select "Grid Scrolling" & decrease zoom to 100%. Results:

1. Settings: Grid scrolling & Show sidebar settings are remembered when openening a new PDF, however zoom level is not remembered (it's always defaulting to automatic zoom when openeing a new PDF, but this happens for standard pdf.js, too)
2. Performance: tested with some PDFs with lots of text and big images. Seems like the same perfromance as standard pdf.js, however standard pdf.js is slower than e.g. foxit pdf reader in many cases, because not enough pages are "read ahead". This means that the loading wheel is shortly visible when scrolling fast. In addition, already read pages are not "remembered" in RAM. Scrolling upwards again shows the loading wheel again. But as said, this seems to be an issue of the general standard pdf.js.
3. Compatibility: tested non-A4 sizes, one PDF with different pages sizes. On one non-standard PDF an header image was missing, but this also happened with the standard pdf.js.
4. Technical: as with my standard FF everything works (sub-pixel font rendering, hardware acceleration...). Also working: PDF/A & PDFs with Javascript actions. Not working are PDFs with text input elements, but again this is also not working with the standard pdf.js ("the PDF contains formular data. the editing of forumulars is not supported").
5. Stress: tested 50 PDFs & some torture ones with thousands of pages.

Maybe I would name it differently (e.g. "Multiple Page View", but I'm not a native speaker. I just didn't realize directly what this setting does).

Conclusion: grid scrolling version is exactly working like the standard non-grid pdf.js. There are some issues with pdf.js in general that could be improved, but nothing related to the grid scrolling PR. The grid scrolling version is absolutely great, it would just be fantastic if the "header bar" would hide automatically. In Chrome's PDF viewer, this bar is only shown for some seconds when the mouse moves, or the screen is touched. Apart from that I'm already thinking how to use this grid scrolling version as my standard PDF reader, until this is available in FF stable ;)

For those looking for a quick clean hack, just add some css magic on (viewer.html):

<style>
#viewer {
  margin-left:20px;
}
div.page {
  float:left;
}
</style>

Set zoom at around 75% (= two page view on my 1440x900 screen)

Is there any reason why this feature should be implemented in pdf.js itself? Implementing it in a reader app based on pdf.js is trivial and does not risk messing up the renderer.

Yes, I agree, i does not need to be in the pdf.js code...

For those looking for a quick clean hack, just add some css magic on (viewer.html)...

Thanks for the work around.

As a sumup, Could someone write an extension that injects @icedman 's workaroud? So that one could toggle 1p/2p view in a single click? I have an extension "Kill Sticky" which injects/modifies the page locally so this should be doable.

Thanks