I implemented PDF.js library and I need to print a PDF from IE 11 (with a click on a button in PDF.js viewer). The problem is, IE adds page information (header, footer, page number), and cuts off text like 5cm to the right. I spent hours trying out different CSS variants for #page rule, but still can't fix it. Here are the pictures.
This is how the printed file should look like:
And this is how it looks like printed to pdf with margin-left and margin-right set to 0mm:
You see, position and size are correct, but the text is simply cut off. Now when I added 50mm to the right margin:
Now the page number is aligned with the document, and the document text is still cut off, but a little less.
I experimented with different values and I get weird results, but I can't get it to show the complete text. Tried all kinds of margins, padding, size, width, overflow: visible... Nothing works. The only way I managed to remove header, footer and page numbers is by manually setting it up in IE print settings. But then again text is cut off. And it shouldn't be the client's job to mess around with print settings, it should automatically work just fine. I found similar problems on SO but no final answer. Is this actually an IE bug which is impossible to solve? Thanks
I believe that you can find more information about this (and other IE) printing issues here:
(IE: Incorrect printing in Internet Explorer)
https://github.com/mozilla/pdf.js/issues/3983
There appears to be a lot of issues around printing in IE 10 and IE 11 using this pdf.js library. I am currently trying to get it to work myself.
(My own problem is that I am getting page 2 content appearing on page 1 and having page 1 content cut off)
this (around line 3469, viewer.js)
canvas.style.width = (PRINT_OUTPUT_SCALE * viewport.width) + 'px';
canvas.style.height = (PRINT_OUTPUT_SCALE * viewport.height) + 'px';
var cssScale = 'scale(1, 1)';
seems to fix the scaling issue for me, and the comment by himawan-r (page setup dialog) around the 25 Apr 2015 told me how to get rid of the headers/footers.
My only real workaround at the moment is to force printing in a PDF plugin, and if the plugin is not installed, default to a standard html page with the relevant CSS queries for stripping non-printable areas.
I hope that this issue is something that is going to get addressed quickly, because I really like the pdf.js library.
Related
Due to Chrome (and other Blink browsers) having a bug where only the first 500 columns are painted i need either a fix/hack, or an alternative solution.
See bug here (there is 509 pages - not 500): https://codepen.io/anon/pen/pLxozK
/* codepen link must be accompanied by code */
column-width: 400px;
I parse EPUB html to a single file. The EPUB's styling must be preserved, so i can't change the html structure.
CSS columns does a good job of rendering such a flat document horizontally. But the 500 limit in Blink means blank pages in Android Webviews.
Is there any workaround for this bug?
Users can adjust font size etc meaning amount of columns can change. So an alternative solution must be able to adjust.
What a cool little bug, I've never seen that before!
By the looks of things you'll need to add display:none to some of your divs. You'll need to use Javascript to see what's in view and see what's not. You'll get the added bonus of not using any system resources unnecessarily as you won't be painting any of the pages that aren't in view.
I am having an issue with a website for our student-organized congress at http://ebspreneurship.de that randomly bugs roughly 1 ever 5 times - sometimes more, sometimes less.
I have three revolution sliders - one is the above-the-fold content (full screen), just under it is the Elements section with another full width revolution slider(RS) and then on the bottom I have this map.
From time to time randomly one of the 2 upper sliders (the last one never bugs) disappears and shows only the background image. I can't trace what's the problem, i spend a few days on that. I notice that if I start many browsers with the website and find one that's bugged, there is an error on Inspect:
Issue at YouTube Video Pause:
(unknown) TypeError: d.getPlayerState is not a function
Still, tried without youtube video and it bugs the same way with only BG image, so that error is for now irrelevant.
I just don't get what's the problem and I tried disabling all plugins, i tried playing with caching methods or disabling it... Nothing changes it...
Any help would be greatly appreciated!
OK, for some reason on random intervals the page loads with my main layer div being with "visibility: hidden;", while the div of the image has "opacity: 0.0001."
So,i went for brute force solution of overriding all div's ids one by one on both sliders.
It worked, since, as seen in the image, the browser loaded with hidden divs and opacity 0.0001, but my override worked and still displayed correctly. Image of how the bug was overridden and displayed correctly
Thank you for the ones that tried to help (I noticed quite a few good souls that as always are found around here)!!
I edited some files (CSS and PHP) on a website. Now Firebug (2.0.9) displays the same line number for every CSS rule within the Style side panel. I've tried uninstalling and re-installing Firebug - no luck.
Even on this website, every rule I inspect says (line 1).
Anyone knows how I can get Firebug to display the correct line numbers again?
Since you say the changes were to the files, not to Firebug, I would say the issue is the CSS file and Firebug is reporting the line number correctly. That is to say there is no new lines in the file - all rules are on a single line.
Take a look at the .css file in a basic text editor and make sure the white space hasn't been removed. If it has, you may still see the text wrap and look to be on separate lines but this is just how the editor is showing it - word wrap can usually be turned on/off in editors.
If it looks like a big block of text then your CSS has been minified most likely.
I am printing my page from IE using javascript print function. The text is way smaller than what it should be.
function BtnPrintClick() {
var printHTML = $('#divPrint').html();
window.innerHTML = "";
window.innerHTML = printHTML;
window.print();
This is my script. Why does it not pick up the font size of the web page? The font is not being resized in any #media print styling. I am using IE9.
When you print a webpage, Internet Explorer shrinks the content of the
webpage to fit the width of your paper. If the webpage is wide,
reducing the text size to fit the page can cause the text to be
unreadably small
http://windows.microsoft.com/en-us/windows7/printing-webpages-in-internet-explorer-9-frequently-asked-questions
The user solutions proposed by microsoft are:
Change print orientation to landscape.
Select portions of the webpage and print them separately. See the question "How do I print specific parts of a webpage?" later in this topic for more information.
Click the Tools button Tools button, point to Print, and then click Print preview. From the Change Print Size menu, choose Custom. Specify how large you would like the webpage to be printed by setting a percentage in the Custom Size text box. This will enlarge the printed size of the entire webpage, but it might result in some of the webpage being cut off on the printed document.
As a developper, you may look at #media to see if it overwrite the print rules of IE9.
Check the percentage size of the impression while printing ... it might be a stupid thing. But I've already faced something similar.
[Please only post an answer if you know the answer really well -- if you post an answer such as "I think it is easy to style it in CSS", then it is a guess and not a real answer, and it will make lots of people skip this question because it is marked as "answered"]
[I know the Share button is to be phased out, replaced by the Like button, but the program management still wants to use it as well as using the Like button]
I see fairly often that the Facebook Share button is faked by using an icon, as a background, and the text "Share" as a "button" -- the icon + text is faked to be 1 button.
Example:
http://www.youtube.com/create_detail/GoAnimate
http://www.pcmag.com/article2/0,2817,2381106,00.asp
The surprising thing is, it actually looks good on FF as well as IE 7. And the top link uses Tahoma font, while the second one uses Verdana for Windows, and "Lucida Grande" for Mac.
Question 1: what is it not made into an image? Because as we all know, an image looks the same almost every where. If you need to align the icon with the text, for all different fonts on different platform - Mac, Win 7, Win XP, Vista, Linux, IE 7, IE 8, FF, Chrome, and make the background of the text blue so that it looks like part of a button, it is going to be hard. Different fonts have different top space and bottom space (the "leading" as in printing terms), so it is hard to align the text well with the icon, and also hard to make the font not to look like grainy text on all platforms.
Question 2: is there a standard library or standard method to do it?
(the long existing <fb-share> as XFBML actually gives you an <a>, with the background icon, and then a <span> inside the <a> tag containing the text "Share". So it is actually just a square icon + text, but such as the second link above, they will fake it as a button. Maybe that's why even when it is not XFBML, some people still show the button this way instead of a good old image)
Update: also, it is hard because they usually are just <span>, and you can't specify a width for a <span>. Also, it has double borders to make it look like 3D, but it looks like 1 border is real CSS border and 1 border is by using the Sprite underneath.
Update 2: By the way, of all the Facebook Share button page that still exist on web, I never saw one with a Bubble with a count... this is getting more mysterious...
There are three good reasons for doing it this way:
Reuse: You can use the same icon on several different buttons, regardless of what the text content of the button is. This means you only have to download the icon once, which saves on bandwidth (see below) and means you don't have to make a different button image for every button you want to provide to the user. This is especially important on multilingual sites, as I'm sure you can imagine.
Bandwidth saving: The small icon used to decorate the text button is a lot smaller than an entire button graphic would be and therefore consumes less bandwidth to download it. While for one button this might not amount to much, it all adds up, especially on a site with potentially hundreds of different buttons that gets the kind of traffic that a site like Youtube or Facebook might get.
Accessibility: Image buttons take some additional work to make them accessible (the addition of an alt tag for example) which can get overlooked by web developers in a hurry. Text buttons are accessible by default because they're, well, text.
As for how to do it well, there's any number of approaches. You could use the <button> tag, though this has its own set of issues in IE, you could use <input type="button" /> and give it a background and padding (so the text doesn't overwrite the background) but that approach will require javascript to make the button actually do anything, <input type="submit" /> (similar to buttons but handling them is done server side instead of with javascript), or you could style <a> tags to look like buttons by giving them a background, white top and left border, black bottom and right border, etc. I'm sure there's others as well that I can't remember off the top of my head.
UPDATE: The OP added an update regarding spans and width. By default, no, you can't give a span a width. If you give it padding you can create space inside for adding the icon as a background image, of course, but if you need to explicitly give a span a width you can do it by setting its cisplay CSS property to block or inline-block (the latter requires a modern browser to work)