Feature/pdf viewer

[mneuwert]

Description

PDF viewer shall be implemented allowing comfortable viewing of PDF files.

Related Issue

#87

Motivation and Context

We would like to utilise PDFKit features to provide user experience similar to iBooks app while browsing PDF files.

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• PDF viewer with thumbnail view which can be hidden
• Go to page X feature
• Search feature showing the hits with page numbers and allowing to jump to selected search hit
• Separate PDF navigation screen with two tabs: table of contents / larger thumbnails for all pages

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[mneuwert]

@jesmrec regarding the thumbnails in the bottom of the PDF viewer, this seems to be sporadic issue and I've seen references to the same problem on stackoverflow. I will try to debug this.. But first debug session has shown that the PDFThumbnailsView is positioned properly. Apple uses collection view which resides within this view and the implementation sometimes seem to decide to set content inset so that the thumbnail cells are shifted to the center. Another case to for the Hopper app to see what's going on in PDFKit:)

UPDATE 16.10.2018:
I could at least narrow down to the case where it happens. The issue appears when the PDF viewer views are layed out but the file is not available since it has not been downloaded yet. Thus PDFDocument object is set later in the PDFView, after the download is finished. So, it seems that PDFThumbnailsView internally isn't laying out private PDFCollectionView_ios properly, which is actually responsible for displaying thumbnails, as long as there is no document. And if the document is added later to PDFView, PDFThumbnailsView isn't able to correct the layout. So, basically I see it as PDFKit bug, but still I would try to find a workaround. There is a private method [PDFCollectionView_ios reloadDataAndRecenter] which can solve this but this is only called upon unlocking a password protected document. But may be also adding PDFThumbnailsView to the view hierarchy only after it is ensured that there is a valid document set in the PDFView would solve this.

[jesmrec]

Regarding this one for which you have attached screenshot, how to re-produce this? I've never seen this issue. The page of pages information shall always appear below the PDF page. Never seen such effect. Is it re-producible with particular document?

I reproduce it with every pdf i tried to, using an iPhone. This is the environment i used:

• iPhone 6SPlus iOS v11.4
• Server {"installed":true,"maintenance":false,"needsDbUpgrade":false,"version":"10.0.9.5","versionstring":"10.0.9","edition":"Community","productname":"ownCloud"}

If you need pdf files which i have reproduce the effect with, let me know and i will send you @mneuwert

[jesmrec]

I could at least narrow down to the case where it happens. The issue appears when the PDF viewer views are layed out but the file is not available since it has not been downloaded yet. Thus PDFDocument object is set later in the PDFView, after the download is finished. So, it seems that PDFThumbnailsView internally isn't laying out private PDFCollectionView_ios properly, which is actually responsible for displaying thumbnails, as long as there is no document. And if the document is added later to PDFView, PDFThumbnailsView isn't able to correct the layout. So, basically I see it as PDFKit bug, but still I would try to find a workaround. There is a private method [PDFCollectionView_ios reloadDataAndRecenter] which can solve this but this is only called upon unlocking a password protected document. But may be also adding PDFThumbnailsView to the view hierarchy only after it is ensured that there is a valid document set in the PDFView would solve this.

awesome research. The point here is: is it better to workaround the problem (not an important problem) than reporting the bug to PDFKit and wait for an "offlicial" fix? when a workaround is included, it is easy to forget the problem and the workarounding code remains there even though the source problem is fixed.

[jesmrec]

• The issue about the page number on the top happens in iOS11. In iOS12 are correctly shown between the preview and the thumbnails

• The thumbnails: the appears in two rows. In the file does not have many pages, it works fine. If the file has a huge amount of pages, the mark moves weirdly when pages are swipped:

• Other detail i did not notice before, the progress bar just below the preview is stucked in the middle of the screen.

[mneuwert]

@jesmrec

• The issue about the page number on the top happens in iOS11. In iOS12 are correctly shown between the preview and the thumbnails

--> Ok, I will check. Unfortunately I think I have no device with iOS11 installed but I will try to link against iOS11 frameworks and use it as deployment target.

• The thumbnails: the appears in two rows. In the file does not have many pages, it works fine. If the file has a huge amount of pages, the mark moves weirdly when pages are swipped:

--> That's a bit tricky since the view with thumbnails is provided by Apple in PDFKit and it itselfs decides based on available space how many thumbnails to show and how many rows are used. I will check how we can tweak it to look good on all possible screen sizes.

• Other detail i did not notice before, the progress bar just below the preview is stucked in the middle of the screen.

--> Do you actually mean the horizontal scroll bar? If yes, then it is fine. It belongs to the scrollview which resides in the PDFView and is not directly accessible.

[jesmrec]

@michaelstingl points that iOS11 is not supported anymore, so no needed there.

In the third comment, yes, i meant the horizontal bar.

[mneuwert]

@felix-schwarz @pablocarmu I integrated master changes and now it is ready for review.

[jesmrec]

Base changed, so the original base is already merged in master. In any case, many commits of other branches are included here. This problem should be fixed to avoid bunch of conflicts.

[mneuwert]

@jesmrec yes, right.. it turned into mess actually. Therefore I thought that may be pragmatic solution would be to integrate PDF viewer into master on entirely new branch since it is quite self-contained. I did that and created new pull request. So this one can be closed and pdfViewer branch can be deleted. cc: @pablocarmu @felix-schwarz New PR is #138