I have been working for hours to figure out why my CSS is not being applied for printing an HTML page. I have created a working example of the markup I am rendering with dompdf:
https://jsfiddle.net/n7Lak0gr/1/
The HTML and CSS is a directory with multiple columns in a table. The rows have an alternating background color, and there are some other styles as well. But upon printing to a PDF, the styles do not show, even if I have media set to all.
Note that if you copy all of the code from this version and create your own local html file, you can see it better, since another issue is that the table overflows into multiple pages when the styles are not applied.
I have reproduced the issue in Chrome, Firefox, and Internet Explorer. And I have tried removing pieces of the CSS, but I cannot figure out why the styles don't show.
It is the default setting of most browsers not to print backgrounds. Obviously this is to save ink/toner.
You can change that setting in the browser preferences, but the bad thing is that you can't influence those via your website - it's purely a decision of the user who does the printing (and most users don't even know about this preference setting)
I figured it out. I had to delete the font cache file dompdf_font_family_cache.php located in sites/all/libraries/dompdf/lib/fonts/.
I was pointed in the right direction after seeing some other errors and viewing this SO answer
Related
I must have some sort of caching issue. I wrote code to create a download button. The button is meant to exist in 6 different colors, for 6 different topics.
Offline, in Local the CSS rules I wrote, display just fine. The button appear in the 6 different colors according to topic (screenshot 1). However, when I upload and update the CSS file to the live website, it doesn't work. The button appears in just 1 color everywhere and centred (screenshot 2).
It's a wordpress website theme, so I purged the cache. I'm using CMD+SHIFT+R to do a hard refresh, I've tried firefox, chrome and safari - also incognito. Nothing.
The width I chose is 250px and on chrome-developer tools it shows 30%.
Based on that I know that chrome uses an older stylesheet. Even if I change the css classes, chrome refuses to adopt the new ones. Also after a week of waiting - for an automatic refresh, the old CSS is still there.
As I said, I already purged the cache and did hardfresh, not sure what else there is to do. Anyone got an idea?
Screenshot 1 - how it's supposed to look
Screenshot 2 - how it currently looks
The actual CSS
CSS that chrome shows
Like ivvija said in the comment. Use a version push on the including URL of your CSS.
<link rel="stylesheet" href="https://yourdomain.com/css/style.css?v=1.0.1a" />
If you have made changes and it doesn't show up, change the version and it should push the new version. This also works for included javascripts btw. It's wise to use this always, specially when you are done with a development change. Else your visitors could experience the same problem. ✌️
Strange bug I fixed once in the past but did not write it down/document it/report it so now I'm lost in the same workframe.
So, it's an Angular 2 app, the content is hardcoded html, no Angular binded variables, data banding or similar.
The bug show up on Chrome, not on Firefox.
If I refresh 10 times in a row, the content will show up sometimes and won't others, there is no pattern or clues about it.
Once the content is hidden, if i change whatever element property, will show up all the content instantly.
I have attached a gif which explains the bug clearly.
Thanks for any idea/suggestion/help :)
EDIT 1:
I just added 2 pictures of the css computed, one with Bootstrap 4 and other without the framework, same result.
Not related at all to Angular or any stuff like that.
I am importing a font from the GoogleFonts page. If I download this font, I get TTF format, which is having a bug on Chrome and does not work properly, but if I link to their server, it's using WOFF2 format.
See this picture attached which it shows the different formats for the same font.
so our site is built on a CMS and is using CMS driven background images on our banners, as such the banners has inline styles on the html element dictating what the background-image was. This all worked fine.
I made a change so that the css is in a style tag just before the element so there is no 'inline styles' on the pages.
This works fine on desktop, when resizing and using mobile browser simulators, but on 2 Android phones I've tested on some pages the banner image shows for a split second and then vanishes. The confusing thing is all the banners on the site use the same css and html, but only certain ones break.
The ones I know that break are on the 'Web Development' and 'Contact Us' pages.
This is not something I have seen happen before, and there is no difference between code on each page, no javascript touching these, and they worked before I made recent changes (of which the only bit effecting these was moving the style from inline into a style tag).
Working page:
https://www.pixelhero.co.uk/web-design-bristol/
Not working:
https://www.pixelhero.co.uk/about-us/
Does anyone have any ideas why this is happening? Or able to check if they see the same problem?
Image file sizes and dimensions don't seem to have any impact either (as often used to be the case)
I'm lost on this one, and can't seem to find an explanation for this use case.
Thanks all
Basically, in IE11, when you try to print preview (or print, for that matter) this page (and a few others on this site), the page never renders in the preview pane and the number of pages climbs up infinitely: http://www.greatjakes.com/recent-work/
This bug can also be found on pages like these:
http://www.greatjakes.com/news/
http://www.greatjakes.com/news/kegler-brown-website-honored-as-one-of-the-top-sites-of-2014/
http://www.greatjakes.com/blog/the-disappearing-homepage-traffic-is-down-17-on-homepages-of-law-firm-websites/
I've only been able to experience it in IE11. IE8 is fine.
It is not JS-related. If you remove the JS from the page, it still occurs.
If you remove the CSS entirely, it goes away, but that is missing the point.
If you remove (using in-browser developer tools) the HTML elements within the #content-inner > .page block one by one, you'll find that the page actually prints properly when you reduce the number of elements down to about 5 (3 in some pages).
Other than that, I have no idea what is going on! Any help would be appreciated.
We managed to narrow the issue down to a single CSS rule:
#footer {
display: inline-block;
}
We solved the problem by changing "inline-block" to just "inline" within the print-only CSS - but that won't help others fix their own problem because the bug probably manifests itself based on a number of random circumstances. It seems the key was to narrow down the cause. To do this, I simply deleted chunks of CSS until the page actually rendered in print preview. Once I deleted the chunk that was causing the problem, I restored everything and then worked within the critical chunk and deleted the CSS rule-by-rule until it worked. Once I figured out the exact line that was causing the bug, we changed the rule within the print-only CSS (no need to change how it looked in the standard CSS).
We have an HTML page which displays a bunch of pretty bars using divs and repeating backgrounds. We are in the process of making a report out of this that can be printed nicely, but this may take some time because we don't have a reporting framework in place. As an interm solution we'd like to make the HTML version printable. The background of the divs are the only problem, and they don't print because of the default setting (which can't be enabled because the workstations are locked down).
I have found a work around for printing background images, but this doesn't work when the background needs to be repeated.
Are there any other work arounds which might be able to help? I have also been trying to insert an image inside the dive and stretch it, but this is throwing off all the other relative positions and is proving to be very difficult to fix. I am still looking into this however.
I have used this ActiveX Component in situations where controlling the printer output was absolutely neccessary (think printing stickers etc).
The function you'd want is : printBackground
However this doesn't come with their free license but perhaps the cost of that license outweigh the other work arounds implementation time.
Drawback: IE only.
If you can educate your users, there is an option in the print dialog box of IE and Firefox that is labeled something like 'Include Background Images' or 'Print Background Images'
This will include repeating background images.
I couldn't load the link, and I may not be understanding the problem correctly, but...
This is more of a work-around than a solution, but would you be able to make a single image that just appears to be repeated? Or at least, is repeated (for variable browser and screen sizes), but is large enough to be 'proper' for printing (which is a much more standard size)?
The easiest way I can think of achieving this is to have different stylesheet for printing that uses standardised images that fit the containers printed on paper.
The display stylesheet would continue to use the repeated images which wouldn't hinder performance as the full images loaded in the print stylesheet would only be loaded when the page is sent to the printer.
...at least, that's what the HTML spec says should happen. Whether this is actually the case, I can't be 100% sure.