Open nemeulenbroek opened 9 years ago
Work is happening in the branch printing
but because of the complex nature of pdf.js, this will be neither simple nor easy, and the solution may not be elegant.
Clarification: I think the current problem is that the areamenus show up when printing, and people don't want them to.
The link tag is somewhat deprecated in favour of @media print
, so that is what was used in the branch.
Actually, besides that, in IE, when you get to print a PDF, it'll split and shrink pages so that you have 1.5 pages of the PDF per page of paper
Because nothing could ever be simple, could it. Any specific versions of ie, or just in general?
No it couldn't. From my info, just in general. For sure with the latest versions running on windows 7 and 8. I as of yet have not been able to find a solution, but I admit that I haven't necessarily tried all options
https://github.com/mozilla/pdf.js/issues/3983 Seems there's not much we can do about ie
Are there any alternatives to this iframe?
What do you mean? We don't use iframes.
Or the importation that we use now
Not really. Nothing so nice at least. Pretty much everything else is based on pdf.js, and so would have the same problem.
Well darn. Should we put a message on the website letting them know what's happening? Or are there any paid alternatives that we can ask about a budget for?
Paid alternatives would open a whole can of worms with licensing, we would likely have to rebuild the website from scratch under a different license, and we probably wouldn't be able to use a public github repository to host the code.
So no.
We may be able to do some javascript funkiness to get the print button built in to the viewer to send the original pdf to the printer, or we may be able to compensate with some hacky css, but beyond that there isn't much to do.
see the printing branch for compensating with hacky css
Actually, if we have to ask for a budget in the first place to fix this, why don't we just switch the repo to a private one, revoke the old license and make it totally private to the school?
Other than that, I agree with you, the only other solutions are really hacky, but hey, at this point, if they work, they work.
We would still have to rebuild the website from scratch
Something I didn't think of before: could we not just link to the media directly with the tag in the header? Totally circumventing the PDF viewer?
I remember looking into that a while ago. I think I found it wouldn't work, but I don't remember why. Will re-investigate.
The upgraded pdf viewer (#161) seems to fix printing, at least on chrome, so this issue may be obsolete.
As for substituting the pdf via link tag, the browser just seems to ignore it. Maybe something to look in to if the upgrade doesn't work, but I'm not going to pursue it just now.
The issue still persists in internet explorer - and that's with the most recent version. Now, however, it's a different error, as shown below As far as I can see from this, the iframe is now feeding IE the pdf, but IE is still overlaying the css from the webpage regardless. Maybe the meta tag to get rid of everything will help, but it seems to be a persistent problem with IE. I'll start a new branch sometime soon, however, experimenting with the tags to see if it'll do the trick
The new viewer hasn't been pushed to the cbe server yet, so you are still looking at the old version
Assuming that the new pdf viewer doesn't fix the problem (and as of this moment it either hasn't or still hasn't been pushed), this is just a note for myself in the future when I have time to fix this: the u of c d2l page uses the same iframe as us combined with a media tag and it works fine
The changes were just pushed recently and needed a refresh to clear the cache, and include ui changes, so I suspect you haven't seen it yet. The new viewer works for me on chrome, but I haven't tested anything else yet.
I did a cache clear recently, so it should have those changes. As long as the update was posted before I posted on here, I would have seen it. I'll check again tonight
Date: Sun, 22 Nov 2015 21:24:21 -0800 From: notifications@github.com To: abe-site@noreply.github.com CC: speedskatesoul@hotmail.ca Subject: Re: [abe-site] Printing (#145)
The changes were just pushed recently and needed a refresh to clear the cache, and include ui changes, so I suspect you haven't seen it yet.
The new viewer works for me on chrome, but I haven't tested anything else yet.
— Reply to this email directly or view it on GitHub.
Did some real testing:
Chrome and Firefox were tested on both OSX and Windows, with no difference between the two.
In order of quality:
Works perfectly if you use the button built into the viewer, otherwise prints just one page, which may be a page from the pdf or may just be blank.
Same as chrome, but adds a header/footer with info about the date, website, etc. That's just a "Safari printing from a website" thing.
Whether using the browser button or the viewer button reproduces the pdf almost perfectly, except that the content is shrunken slightly on each page.
Using the viewer button loads more slowly than other browsers, results in good scale, but only shows the top half of every page (wtf?) Using the browser button gives same results as chrome (one page, maybe blank).
Printing is much improved, especially on chrome, but not yet fixed.
As for the link tag, it doesn't seem to do anything.
As discussed, here's one of the current options:
<link rel="stylesheet" type="text/css" href="print.css" media="print">
This link tag will only trigger when you try to print because of the 'media="print"' command. This can link to any type of file that the link tag normally can. As an example of what's commonly done with it, here's a link: http://www.w3schools.com/tags/tryhtml_link_media.htm. Just click ctrl+p while viewing the page