The screen height and width are going to be slightly less than that to account for start bars/menus etc.
my full screen browser’s size is 1903 × 1006
This may help:
Referencing the screen size breakpoints that Bootstrap uses for responsive design many people consider the lg breakpoint at ≥992px to be the “tablet to desktop” breakpoint.
Have you tried using the Google document viewer workaround for displaying a PDF? It’s working quite well on my iPad here in both Safari and Firefox with the dummy pdf example.
Didn’t work on the desktop. Thanks
If IOS is hiding itself, can you detect Windows, Linux and Android and make a guess ?
I’ve been trying to find the command that gets me screen width and height and can’t find one that actually works. I must be missing something . . .
I couldn’t find anything in-framework either. I created a simple custom web control to grab the screen size.
I also haven’t had any issues with the Google PDF viewer on Desktop. I’ve included the technique in the project with the screen size grabber.
Download: ScreenSizeWeb.xojo_xml_project
If you can’t detect Mac OS either, probably not.
I’d like to point out that one of the goals in web 2 was to not do device detection and instead to feature detection because it is better to figure out what a browser is capable of than trying to put in device or browser specific hacks. You will almost always get silently bitten by that later when the browser changes something during an update anyway.
The framework doesn’t include a PDF viewer. John says that using the Google viewer isn’t working, but I’m not sure we can feature-detect that.
If you could write a feature detection script for the ability to display PDF in a HTMLViewer, it would come in handy. So many people are under the false impression that HTMLViewer to display PDF is a good idea. This problem gets worse since there’s an ill-advised official blog posts suggesting the practice.
Displaying PDF seems like a hot topic in StackOverflow:
I think the big problem is what HTMLViewer actually is in a web project. The fact that it’s technically a “frame” and that frames really have fallen out of favor over the last few years (because of security concerns mostly) makes them very hard to push into being what we want here. This is why most sites offer only a download option and then let the browsers do what they’re going to do.
That said, there is a very good pdf viewer written in pure JavaScript out there that I hear Firefox used in their browser.
I’ve used this one from Mozilla in a few years ago and, at least back then, it looked like the best option:
It’s from Mozilla, so probably is the same one you’re talking about, Greg.
Demo:
https://mozilla.github.io/pdf.js/web/viewer.html
More examples:
1 Like
Yep. That’s the one. I suspect that could be relatively easily made into a custom control.
1 Like
Ah!, I wasn’t aware Anthony, thank you.
Then I am putting this solely on Apples feet. If the browser is not going to identify itself, and each browser is going to behave differently then the Internet will be broken. Good luck with functioning web apps for any language going forward.
I don’t think it matters. If the browsers are going to continue to be functionally different, then not allow to detect for it, you are just going to end up with code that does not work on some browsers.
Apple did it to protect the privacy of users from malicious advertisers. If you want to blame someone, blame advertisers.
As far as breaking the web goes, responsive design and feature detection keep things rolling. Most developers do not need to know the device the user has. I have been trying to help OP solve their root problem instead of rely on device detection.
This is why developers should use a Javascript PDF viewer like Anthony’s or the Google one that seems to work embedded in an iframe. I am extremely curious about the issues OP is having as I would like to not encounter them myself.
3 Likes