I have been experiencing the weirdest problem, that I can't even begin to troubleshoot. It is important that the webpage in this project I am working is 100% printable. As you can see the signature field below and the note field (with the string "erererer") shows great in Google Chromes print preview but not when I actually print it out using the Chrome browser. In fact, the note field just prints out the border and nothing else (looks like a white empty div with a border) and the signature field prints out everything but the actual signature. When I use google chrome to save the document as a PDF and then print it out directly from the PDF everything prints perfect. When I use firefox to print, the signature area prints perfect, but the note problem remains of it only printing the outter border.
I would greatly appreciate any suggestions on how to begin to fix this or any input on why this may be happening.
Many thanks in advance!
If you need accurate & reliable printability, going iText and PDF is a solution. You can render the page as PDF and it will show in the browser, and then print exactly as specified.
HTML is often inexact, has marks (page numbers etc) from the browser, and can be glitchy.
iText (latest versions) are available open-source, or commercially. There's also an older version available free. See: What is latest version of itext that is not AGPL?
As for your note field: maybe there's something weird with backgrounds, non-standard styling? , or fonts that aren't present? Try making it a plain vanilla table.
Related
I'm working on a webpage that has a different "print to PDF" result (after Ctrl+P -> Save to PDF in Chrome) than the original web display by using #media print in the CSS code.
I'm using a variable font with the parameter font-variation-settings:"wght", but the generated PDF seems to ignore this parameter when used in #media print.
Yet, when using the Chrome tool "Inspector>Rendering>Print emulate CSS media type", changes of this parameter are taken into account in the displayed web page!
Looks like the problem comes from the Ctrl+P interface, any ideas on how to handle this?
Thank you in advance.
Please see https://bugs.chromium.org/p/chromium/issues/detail?id=1070089 - this should be fixed now, you may want to retest with a recent Chrome Canary build and see if the issue is indeed gone.
We're using Barlow, available for free from Google fonts, in a web app. Here's the way a sample phrase looks when rendered on Google's example page. (If you want to reproduce it, you will need to enter the custom text yourself and adjust the slider to 14px.)
Note, in particular, the distinct space between the bottom of the i and its dot above, as well as the clarity of the top part of the f.
This is how the same phrase looks when rendered in our app, as reproduced in this Code Pen.
Note the muddy space between the i and its dot, as well as the muddy top curve to the f.
I've tried looking through all the styles on the elements in question, and I can't find any style that should affect these differently. The network tab clearly shows that the bold version of the font is being loaded; it doesn't look as if this could be faux bold.
This may seem trivial, but we've actually had quite a few complaints about how the font looks in our app, specifically that the bold, lowercase i looks like an l.
Anyone have an idea what might be happening here?
Update: Using Chrome on a Mac; I can confirm the same issue in Firefox. This is on an external display... on a retina there's no problem, as there is way more detail.
The problem turned out to be a problem with the source repo: "hinting got missed in the most recent commit" and the Google specimen (which looked correct) was "actually running an earlier version."
Happily, the maintainer was able to get the problem fixed with a subsequent version.
I have a very pretty calendar report that I've created on one machine, that shows my company's daily revenue as a color coded block for every day for the past several years. After finally getting a color scheme down and pretty much finalizing it, I went to test it on another machine - and hit a rather large obstacle.
This is the report that I used as a template:
http://bl.ocks.org/mbostock/4063318
It's awesome. And, inside Internet Explorer 11, it looks fantastic. I never would have expected that copying the code and testing the report would produce a blank page, but there it is. On that page, the calendar report is visible. In IE 11. Copying the code to a new html file and opening it, shows nothing. In Firefox, however, everything is visible. as is.
Now, there's a part of that page that points to "//d3js.org/d3.v3.min.js"
And I figured out that in order to make that work in firefox I had to add the http: in front, so that's not my issue.
I'm literally sitting here at my desk staring at two browser windows open and pointing to the same html file. One contains my beautiful report, one is a completely blank page.
Some cursory google searches reveal that IE 8 or lower have issues with the svg. I can't seem to find any references on someone having a similar issue though. Their situation seems to be that with IE10, you need to specify the height and width, not just one or the other, to make sure everything scales properly.
If I could have my way, I'd just run Firefox on all of the machines that are going to run the report, even if it's just for that one thing! Alas, I am but a mere peasant coder and so I have to make it work. in the dreaded IE.
Are there any svg/html/d3.js coders out there that can tell me another way to spit out the data I'm using so that I can get what I'm looking for?
copying the code and testing the report would produce a blank page
Because you're outputting invalid HTML. There is no html or head element for starters.
Output your code in to a file like example.xhtml and open it in Firefox (specifically) as it's XML parser will very quickly tell you what line and column the first XML parser error is occurring on. You are rendering in standards mode instead of quirks though that does not imply your page meets standards.
var m=(document.compatMode == 'CSS1Compat') ? 'Standards' : 'Quirks'; window.alert(m+'-mode.');
I was making a presentation using Google slides (in Chinese) and when I want to preview it in presentation mode, "some" of the font looks different from editor mode.
The sample here
I've tried searching on Google and found only this discussion thread, but my problem is a little bit different. The font changes when I change it in the editor and in the presentation mode, the "character" somehow just looks different in presentation mode(the font style is correct). I have tried Safari, Chrome, Firefox, but all fails.
Is this like a bug only for Chinese characters? English seems perfectly fine to me. Does anyone have the same problem and knows how to resolve it?
Actually this happens to many other languages (like JP, KO, etc.) as well.
It gets rendered differently from editor to presentation mode.
So, here is the quick fix for the issue.
Use 'ShowAsIs' Chrome extension to fix it.
https://www.youtube.com/watch?v=Rt4xnAFFGik
Disclaimer: I am the developer of the extension.
This may sound like a SuperUser issue, but I wrote the page in question and I'm wondering if there is something I can do to fix the problem....
I have a page in production that simlply displays data in a bunch of tables. Our employees basically go to this page to print a form with our clients information filled in for them. Today for a specific client the page is not printing. I've tried printing using IE 7 and 8 as well as Chrome on Windows XP and Windows 7. This client's data is by no means make the page longer or contain more data that others clients.
Symptoms:
Does NOT print using IE8 or IE7 on WinXP and Windows 7.
DOES print with Chrome.
The page to print is displayed fine as a far as the actual web page goes... it scrolls, there are no errors and and nothing seems to be wrong with the page.
When using IE to print, the document just spools with out actually printing out...I end up canceling the document from the printers window.
When viewing print preview the first page is displayed, but when we try to go to the second page in the print preview IE locks up.
This does not happen for every client, but when it does happen it can be reproduced.
The page is pretty long and has client info that is keeping me from just copy and pasting the markup for you guys. I am hopeing that some one else has experienced a similiar issue in IE and has some advice.
NOTE: The users are not allowed to use other browsers, so save the IE flamming please.
Hmmm, very hard to tell without markup.
Just to throw some ideas:
Are you using anything difficult on the pages, like Flash or Java?
Custom fonts / cufon?
Huge downscaled images?
opacity or IE specific crazy filter CSS rules?
A huge structure that IE doesn't manage to break up into pages, e.g. a giant table with position: absolute ?
If you use images, try turning off the images. Try turning off CSS.
A few things to try when debugging:
Switch everything over to a standard font and font size (e.g. Arial 12px).
Eliminate all CSS and JavaScript, and if that fixes it then you can narrow down from there by taking out chunk by chunk until it starts working.
If that doesn't work, try cutting down the content significantly to see if it will show up.