The second and newer example called “Scanned PDF display problem” is the better one, with the larger PDF eckardt_Entwicklung_Psychologie.pdf. And it uses HTMLViewer1.loadURL. It shows the artifact that is the subject of the report. The problem becomes more serious as the size of the PDF increases. Try that example.
I guess you mean Scanned_PDF_display_problem.zip, as eckardt_Entwicklung_Psychologie.pdf does not contain any project.
Running Scanned PDF display problem.xojo_binary_project with eckardt_Entwicklung_Psychologie.pdf I scrolled up and down several page for severals minutes without seeing any drawing issue under 10.11.4 and 2015R4.1.
You don’t see the white gap at the bottom of the window? If not, make sure that “Automatically Resize” is checked, or better yet Zoom In (right-click on the image). This is what I see.
I don’t know where I should check “Automatically resize”, but even when I zoom in to obtain the same rendition as what you posted, I never see the white area.
As I said, right-click on the image, and where you found Zoom you’ll see all sizing options. I’d like for you to send me an example of what you see if you don’t mind. I’ll open a private channel.
I have compiled it : MyApplication.app.zip
I thought about a possible cause : slow disk. I have an SSD, so it is possible that alleviates the issue.
Here’s what I see. I’m on a 2013 Mac with a HD, but I see the same issues on the latest Retina iMac with an SSD.
Your link seems broken.
FWIW, I downloaded and ran Michel’s compiled app, and on my 2014 MacBook Pro (SSD), I can see no problems when scrolling a 4 page PDF, three pages of which are full-page scanned images - no white areas…
You posted your local path. Upload it to Dropbox or a web site and post the URL.
[quote=255479:@Peter Truskier]Your link seems broken.
FWIW, I downloaded and ran Michel’s compiled app, and on my 2014 MacBook Pro (SSD), I can see no problems when scrolling a 4 page PDF, three pages of which are full-page scanned images - no white areas…[/quote]
Actually, the original suspicion (which was made years ago) that it was scanning that mattered was wrong. It’s the size of the PDF that matters. You have to use large PDFs (I provide one in the example).
Sorry about the link, this should be correct.
Michel, you’re not seeing a problem because you’re using the Adobe PDF plug-in to render PDFs in WebKit-enabled apps. If you disable their plug-in you’ll see the issue.
I just tried it with an 88 MB PDF, also with no problems.
This is probably what’s going on for me as well. Quickly, how do I disable it?
Well that’s exactly what I had already done, and after quitting all browsers and re-launching Michel’s built app, I still see no problems on my 88 MB PDF.
Out of curiosity, if it’s the reliance on the Mac OS X renderer that’s causing the problem, why not just use the Adobe renderer?
Did you reboot your Mac?
This problem is not specific to HTMLViewer, it affects any large PDF rendered by PDF Kit. I have written a PDF annotation class that uses PDF Kit and see the same problem that is exposed in the HTMLViewer (and have seen it whether using APIs in MacOSLIb or in the MBS PDFKit APIs). The same PDF Kit APIs work fine when making an XCode app. Since HTMLViewer uses PDF Kit to render PDFs, I thought it would be easier to demonstrate the problem using it for the example.
No, but even without doing so, after relaunching Safari, I saw a difference in how PDFs were rendered, so I assumed the Adobe plug-in was out of the picture. I don’t have time right now to keep playing with this, but will try to get back to it.[quote=255496:@Jonathan Ashwell]Since HTMLViewer uses PDF Kit to render PDFs, I thought it would be easier to demonstrate the problem using it for the example.[/quote]
I see. Good luck…
OK. I see the same issue after removing the Adobe Reader plugin. That was a MAJOR detail you left out in the bug report. I just posted a message about it.
I am not so sure the bug is entirely on Xojo. Could very well be a bug in the framework PDF support.
Now, call me blunt, but I think the best workaround if I was to display PDF would be to make the HTMLViewer some 25% higher, and that should mitigate the issue. I tried on the test program and it works just fine. The beauty of PDF is that it scrolls, so even when the plugin is present, there will be no difference.
That’s not a general solution. I have example PDFs where you have to scroll down 20 pages of white space until you get a renderable page.
These artifacts are not due to a bug in the PDF Kit framework. As I’ve said ad infinitum, the same code works just fine in Xcode (I’ve done it). And I’ve talked with others who have written PDF Kit apps. They use the same code as I do for rendering a PDF (there’s not much to it – you just load a PDFDocument into a PDFView. PDFKit takes care of the rendering and scrolling). Until proven otherwise, this is Xojo-specific.
[quote=255521:@Jonathan Ashwell]That’s not a general solution. I have example PDFs where you have to scroll down 20 pages of white space until you get a renderable page.
These artifacts are not due to a bug in the PDF Kit framework. As I’ve said ad infinitum, the same code works just fine in Xcode (I’ve done it). And I’ve talked with others who have written PDF Kit apps. They use the same code as I do for rendering a PDF (there’s not much to it – you just load a PDFDocument into a PDFView. PDFKit takes care of the rendering and scrolling). Until proven otherwise, this is Xojo-specific.[/quote]
Forgive me, but I would never presume anything to be so easy to fix. I know all too well how in my own code things that appear elementary to the user are in fact rather complex.
AFAIK HTMLVIewer is not a PDFView. From what I understand it is an implementation of Safari WebKit. Without having a thorough knowledge of Xojo’s source code, it would be presumptuous to guess where things go wrong. All we know is that when no plugin is used, it happens. But the fact that the plugin fixes it is indicative of something wrong within the way the default renderer works.
The benefit of having revived this thread is that finally, there is a way to reproduce the bug you described. Until you posted that it was necessary to remove the Adobe Reader plugin, Xojo was in the dark. Now they have something solid to go on. Hopefully they will get some time to look into it, between the numerous tasks they currently have on their plate.
In the meantime, you seem to have the solution ready in XCode : does not seems so difficult to create a helper which sole purpose is to display PDF correctly.