This question is not answered. Helpful answers available: 0. Correct answers available: 1.


Permlink Replies: 20 - Pages: 2 [ 1 2 | Next ] - Last Post: 27 Nov 21, 19:05 Last Post By: John-Simpson Threads: [ Previous | Next ]
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Displaying Problems with PDF in Jupiter
Posted: 21 Nov 21, 17:13
 
  Click to reply to this thread Reply
I still use GROMIT and PDF's display fine, however in JUPITER they don't. Am I doing something wrong?

The first thing is that they don't fill the page on PC's with wide screens and on my Android Tablet and Phone they don't show at all!

I attach screenshots of:
1. Jupiter - Chrome Android
2. Jupiter - Chrome PC
3. Gromit - Chrome PC
4. Gromit - Chrome PC (zoomed)

In Gromit PDF's open in a new browser tab which appears to work fine in my opinion. They are not restricted in width by the PDF viewer in Jupiter. Unfortunately, I think that the Android experience with Jupiter PDFs will put people off from looking at my PDFs.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 21 Nov 21, 18:40   in response to: John-Simpson in response to: John-Simpson
Helpful
  Click to reply to this thread Reply
First, let's address the question of PDF's on a normal PC (desktop, laptop). Both Gromit and Jupiter simply toss the PDF to the browser, and its native ability to display PDF's. The difference is that Gromit opened the PDF in a new tab, whereas Jupiter shows it in a window in the current tab, just like the images

I don't like sending a visitor outside of the album unnecessarily. That leaves him in a place where, suddenly, the album navigation has disappeared. Some visitors will then be very puzzled about how to get back to the album - there are no navigation arrows, and the browser's "back" button doesn't take him there, either.

In Jupiter, the size of the display window for a PDF is governed by the maximum slide image height. So, if your image bounds are 1600x750, the PDF will be shown in a 750x750 box, responsive to the viewport. Your images won't ever be more than 750px tall, so the PDF is consistent. If you want them to display larger, choose larger image bounds, like 1600x1600.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 21 Nov 21, 18:46   in response to: JeffTucker in response to: JeffTucker
Helpful
  Click to reply to this thread Reply
Now let's talk about the wonderful world of Android browsers. I think you'll discover that in either skin, a PDF won't display in either Chrome or Firefox for Android. It can't. Neither browser has any support for PDF's.

The behavior is a little different in the two browsers, but in effect, the phone/tablet just downloads the PDF and then starts looking for a default app to show it. I have the Foxit PDF Viewer on my phone, but you might find the PDF opening in something as strange as the Kindle app.

Eventually the Android browsers will catch up, but it appears that they still just don't have the horsepower needed to deal with PDF's. (I'm not sure what Safari does on an iPhone, but since it's based on the Chrome engine, I'm guessing it doesn't do any better.)

There is one workaround that I have used in some of my skins, but I've abandoned it. Laza is still using it in his skins, however. The workaround relies on tapping into an undocumented "feature" of the Google Docs Viewer, which is actually intended for viewing cloud-based documents. I've found it to be unreliable, sometimes failing to load and leaving the visitor staring at a blank box. But it's also the sort of thing that could vanish tomorrow - Google doesn't support it, and they could shut the door on this use of it in a heartbeat.
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 21:03   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
JeffTucker wrote:


I don't like sending a visitor outside of the album unnecessarily. That leaves him in a place where, suddenly, the album navigation has disappeared. Some visitors will then be very puzzled about how to get back to the album - there are no navigation arrows, and the browser's "back" button doesn't take him there, either.

I can understand that but coming out of the Album and into a new tab has the advantage of being able to display the PDF in the whole of the browser window.

In Jupiter, the size of the display window for a PDF is governed by the maximum slide image height. So, if your image bounds are 1600x750, the PDF will be shown in a 750x750 box, responsive to the viewport. Your images won't ever be more than 750px tall, so the PDF is consistent. If you want them to display larger, choose larger image bounds, like 1600x1600.
I have increased the image bounds from 1500x900 to 1500x1200 and it makes no difference to how the PDF is displayed on my PC. I think this is because responsive is set in Jupiter which keeps the height within the window. (I recall Gromit had options regarding this!)
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 21:21   in response to: John-Simpson in response to: John-Simpson
 
  Click to reply to this thread Reply
In either skin, the PDF is shown as large as it can be, given the size of the browser window, and you have to scroll up and down to see the rest of the PDF. In Jupiter, you're still within the album, with a page title and navigation. In Gromit, you're not, which leaves a few more lines of screen real estate to show the PDF, but leaves the visitor in no-man's-land. But otherwise, there's not a lot of difference.

In any event, it's not going to change.
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 21:24   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
JeffTucker wrote:
Now let's talk about the wonderful world of Android browsers. I think you'll discover that in either skin, a PDF won't display in either Chrome or Firefox for Android. It can't. Neither browser has any support for PDF's.

The behaviour is a little different in the two browsers, but in effect, the phone/tablet just downloads the PDF and then starts looking for a default app to show it.


Android asks me where I want to download it to on my tablet - either Downloads or SD card and then loads it up. (as you said) It isn't the best user experience in my opinion, but this aspect appears to be out of our control! At least on a tablet, the PDF fits the whole of the screen!

Thanks for your advice.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 21:30   in response to: John-Simpson in response to: John-Simpson
 
  Click to reply to this thread Reply
If you don't have an app on your phone that can handle PDF's, you can't view them at all. None of the standard apps do the trick. How many visitors will have a PDF viewer installed?
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 21:52   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment 2021-11-22.png (2.1 MB)
Attachment 2021-11-22 (1).png (500.2 KB)
JeffTucker wrote:
In either skin, the PDF is shown as large as it can be, given the size of the browser window, and you have to scroll up and down to see the rest of the PDF. In Jupiter, you're still within the album, with a page title and navigation. In Gromit, you're not, which leaves a few more lines of screen real estate to show the PDF, but leaves the visitor in no-man's-land. But otherwise, there's not a lot of difference.

In any event, it's not going to change.


Sorry to hear that!

The 2 screenshots show how a very wide PDF displays. Firstly in the browser window in your JUPITER album and secondly as downloaded and opened up in Google Chrome.

I think in this case I'll just post in a jPEG instead. (and tick the image as download original in jAlbum)

I just wonder what was the reason you chose PDF width to be equal to height? I bet that there is a good reason, but with my lack of knowledge, I just don't see it.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 22:26   in response to: John-Simpson in response to: John-Simpson
 
  Click to reply to this thread Reply
Attachment ss009446.png (2.6 MB)
The problem is that a PDF has no native dimensions, unlike a JPG. The skin can't tell whether you're feeding it a scanned document, with typical 8.5" x 11" pages, or whether it's a scanned panorama map of the Engadine Valley. The critical factor, it turns out, is the aspect ratio, but a PDF can't tell you what its aspect ratio is. If it could do that, the display could be tailored better to the material. The best the skin can do is assume a 1:1 AR.

See the attached screenshot. But to do this, I had to measure the PDF, compute the aspect ratio, and manually edit the slide page. But for material like this, converting it to a JPG before using it in the project is the way to go.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 22 Nov 21, 22:42   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment normal.png (1.2 MB)
Attachment maxedout.png (1.4 MB)
And with more "normal" material, forcing the aspect ratio to typical monitor dimensions produces some nasty results. Compare the two screenshots, where "normal" is what the skin does on its own, and "maxedout" is what happens when I manually force it to use more of the width. Not really what a user expects, I think.

I wish I had a dollar for every time a user has said, "Why don't you just....," as if the solution were simple. ;)
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Re: Displaying Problems with PDF in Jupiter
Posted: 23 Nov 21, 19:40   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment variables.jpg (242.7 KB)
In the latter example, the Web User could always scroll down to see what delights might be hidden below! :) For an image of text that is not really a problem, but as you say - for a picture, most Web Users would want the whole image displayed in the whole of the screen of whatever device - large or small that they are using.

Getting back to the PDF viewers, I had wondered if there was a way of easily altering the viewer width, by putting a dimension or two in variables much like could be done for images? (not sure if it still works because I don't use it!) See screenshot attached.

Otherwise, this just ends this PDF discussion, I think! Thanks.
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 23 Nov 21, 22:06   in response to: John-Simpson in response to: John-Simpson
 
  Click to reply to this thread Reply
I'll mull it over. The tough thing is providing an easy way to specify the aspect ratio - relying just on one dimension or the other won't really cut it. It ends up being one of those cases in which writing the user's manual entry is tougher than doing the coding.

When my Xmas Big Bag O' Kronor arrives from Stockholm, maybe I'll be feeling expansive.
John-Simpson

Posts: 108
Registered: 15-Jan-2008
Re: Displaying Problems with PDF in Jupiter
Posted: 24 Nov 21, 10:47   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Well thanks if you do, but I wouldn't be upset if you don't. Firstly it won't fix the display problem with android etc. and secondly, many of my PDFs are A4, A5 portrait size and display okay on the Windows PC. Those sizes that don't display so well on Windows can easily be downloaded and opened up in Chrome, MS Edge or PDF viewer. (For example, scans of a whole newspaper pages) I can appreciate the problems of making changes. There may be unintended consequences and also as you say, keeping track of changes in the instruction manual. Of course it might be useful exercise for your other skins.

Just a couple of random thoughts!
1. Can the PDF window be contained within the maximum size of the website display?
2. Entering data into variables has to be exact and not something the novice would want to do without referring to the syntax each time.

Enjoy your beer. (You more than deserve it.)

Edited by: John-Simpson on 24 Nov 2021, 09:48
jimberry

Posts: 566
Registered: 30-Aug-2004
Re: Displaying Problems with PDF in Jupiter
Posted: 27 Nov 21, 03:04   in response to: John-Simpson in response to: John-Simpson
 
  Click to reply to this thread Reply
John-Simpson wrote:
I think in this case I'll just post in a jPEG instead. (and tick the image as download original in jAlbum)
One of the disadvantages of converting a PDF file to a jPEG file might be that it would not be possible for the end user to extract portions of the document using Cut&Paste.

If you have created the pdf file using a word processing application such as MS Word or LibreOffice Writer, the resulting document can also be saved as an HTML document which would be easier to incorporate into your jAlbum project.

The resulting page may not display as you would wish, but you could apply some CSS to format it better.

JeffTucker wrote:
I don't like sending a visitor outside of the album unnecessarily. That leaves him in a place where, suddenly, the album navigation has disappeared. Some visitors will then be very puzzled about how to get back to the album - there are no navigation arrows, and the browser's "back" button doesn't take him there, either.
If you are incuding in your album pages a "header.inc" with a navigation bar, you can add the same code to your ex-PDF page(s).

Edited by: jimberry on 27 Nov 2021, 10:09
JeffTucker

Posts: 8,105
Registered: 31-Jan-2006
Re: Displaying Problems with PDF in Jupiter
Posted: 27 Nov 21, 06:26   in response to: jimberry in response to: jimberry
 
  Click to reply to this thread Reply
jimberry wrote:
If you are incuding in your album pages a "header.inc" with a navigation bar, you can add the same code to your ex-PDF page(s).

You might want to mull that over for a moment. ;)

In my lightbox skins, the PDF's are opened in the lightbox, just like images and videos, complete with navigation. In my "slide page" skins, the PDF's are opened on their own HTML pages, just like images and videos, complete with navigation. How would using a header.inc be any different?

John likes opening the PDF raw, in the browser, without giving any space to skin page content, like navigation. I think that's a bad idea from the perspective of the site visitor. Granted, it allows the maximum space to view the PDF, but you could say the same thing about JPG's. Why not open those raw in a new browser tab? That would get rid of all those pesky navigation arrows and captions!
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums