I am creating a pdf document (via ColdFusion), but when I preview the rendered pdf in Firefox, I get the number "4" where my checkmarks are supposed to be (see photo below). When I preview the exact same pdf in Chrome or IE, I see the checkmark, and it all works perfectly!
I am pre-populating the pdf form fields (via ColdFusion session variables), and then rendering the pdf using the following markup:
<cfpdfform source="82040.pdf" action="populate">
<cfpdfformparam name="org" value="">
</cfpdfform>
Here is the resulting pdf form in Internet Explorer:
Note how the checkmark is rendered properly:
Here is the same form previewed in FireFox:
Note how the the checkbox has a "4" instead of a checkmark:
Any help would be greatly appreciated!
It is a bug with Firefox's PDF Viewer. Currently, there is no fix. As radiovisual's post points out, the bug in the underlying library (pdf.js) was supposedly fixed. However, there is still the issue of Mozilla updating the older version baked into Firefox (which is what most folks are using). Currently, that bug is still outstanding.
Probably the best you can do is to return the pdf as an "attachment", rather than "inline", so the browser prompts them to "open/save" the file. If the user opts to "open" the pdf, it should open with their default program instead. (Adobe Reader is the default for most users).
<cfheader name="Content-Disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" .../>
Update:
This bug was apparently addressed already, as pointed out via the project's github repo: the bug was supposedly fixed during this commit. So if you are still experiencing problems, it either means:
You are using an outdated version of the pdf.js library,
Or, the problem has been re-introduced into the library.
So to start things off, you will want to make sure that you are using the most up-to-date version of the pdf.js library. If you are still experiencing problems, even with the most up-to-date version, then the problem is still within the embedded pdf document viewer, and there aren't too many things you can do to fix this until the project maintainer's finally fix the problem.
The issue you are experiencing (the reason why you are seeing a "4" where there should be a checkmark, is because the pdf.js library is using a special symbol font to render the checkmarks, but in problematic versions of firefox's embedded pdf-viewer the symbol font isn't rendering the checkmark correctly, so it shows a "4" instead of a checkmark -- because the checkmark symbol they are using in the custom font just so happens to be mapped to the number "4".
Similarly, for the same reasons cited above, if you assign the checkbox to render squares (instead of checks), the letter "N" will appear in the checkbox instead of a square, because the square shape symbol is mapped to the letter "N".
This problem only exists in the embedded pdf document viewer in Firefox but will look perfectly normal when viewed in Adobe Acrobat Reader, or other offline pdf readers (and other browser pdf readers, which is why it looks fine in Chrome and IE), so when users download the form, it will appear like you would expect it to.
Some workarounds / optimizations you could try:
Try one of these, or all of these, they are in no particular order (or guaranteed to work)
Don't rely on the built-in pdf.js browser extension in firefox, instead, make your own updated version based on the latest pdf.js source or target another pdf library and use it's browser-agnostic API to render and display your pdfs.
Create an HTML form for the user to fill and verify all the information, then render the pdf based on the data supplied by the HTML form, for download only (no previewing in the browser). This will force them to open the pdf in their default pdf viewer where the issue is not present, because, again, the problem you describe only happens in Firefox's embedded pdf viewer and not in other pdf viewers like Adobe Acrobat).
Make sure you have the ZapfDingBats Font installed on your server. I haven't confirmed this, but that commit that was supposed to have solved this issue seems to have added support for this font, so it is worth a try to make sure this font is accessible on your ColdFusion server, then try previewing the rendered pdf in Firefox.
Detect that the user is accessing your form via Firefox, and if so, warn the users of the issue, but assure them that downloading the form and viewing in their default pdf viewer will work as expected.
Convert the page to HTML5 (if you aren't already), then add in an HTML5 shiv (so HTML5 features can be used on older browsers), and a CSS normalizer, and test if the problem persists using these optimal settings. It's worth a shot to make sure that the problem is somehow treated differently under the HTML5 standard, since not everyone is having the same issues as you.
Lastly, make sure that your HTML is being rendered as valid markup via your ColdFusion output by using an HTML validator.
Other than that, there isn't a whole lot you can do until the mozilla team updates their embedded pdf viewer. But since the problem is only in the firefox viewer, and not in the pdf itself, it it up to you to decide if this is a deal-breaker or not, and search for alternatives.
Note: PDF.js is built into version 19+ of Firefox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update: You can use this pdf (which represents the character mapping of the ZapDingbats symbol font) as a way of testing your browser's interpretation of embedded fonts in the pdf rendered via pdf.js. Note that at the time of this writing, the above pdf does not display the Zapf Dingbats properly in Firefox (via pdf.js), but other browsers render them just fine (notice the "4" next to a20[x2714] in firefox, and the checkmark next to the same entry (a20[x2714]) in Chrome.
Link to the tutorial
I am trying to get to grips with Firefox SDK development using the tutorials on MDN. The annotator tutorials seem very good but CFX Run fails on the first control stage.
The tutorial uses the widget API that was deprecated in Firefox 29 but I tried downgrading Firefox 28 and the tutorial still doesn't work even when I am copy and pasting the code directly from the page code. When I come to the end of the Implementing the widget page I only get the following message when trying to click the widget icon (the first time, then nothing hapens).
(C:\Users\myname\Firefoxplayground\addon-sdk-1.16) C:\Users\myname\Firefoxplay
ground\pageMod>cfx run
Using binary at 'C:\Program Files (x86)\Mozilla Firefox\firefox.exe'.
Using profile at 'c:\users\sigvard\appdata\local\temp\tmpg3kq0j.mozrunner'.
console.error: pagemod:
Error opening input stream (invalid filename?)
JavaScript strict warning: chrome://browser/content/urlbarBindings.xml, line 666
: reference to undefined property this._value
JavaScript error: chrome://browser/content/urlbarBindings.xml, line 648: aUrl is
undefined
The issue was caused by a bug in the Firefox SDK.
Updating to Firefox SDK 1.16 and initializing a new folder for the project solved it.
We have a chart that is rendering incorrectly in IE8. We just updated the Highcharts.js file yesterday with the latest version as we were receiving a script error on "d.join". Now we don't get any script error and our page continues to load properly, a step in the right direction, however the chart is missing the axis and plot lines and the coloring.
Here is what the chart looks like in Chrome/IE10/IE9:
and in IE 8:
Please help me figure this out. Thanks!
It looks like your problem is due to upgrading to jQuery 2.x. jQuery has intentionally dropped support for Internet Explorer 8 and below. See http://blog.jquery.com/2013/04/18/jquery-2-0-released/
Your solution would be to either
Downgrade to jQuery 1.x
Drop your support for Internet Explorer 8
I need to display an alert box in other than English language for which I am making use of bean message using Application Resource properties file. The code written in JSP works perfect in Firefox but in IE the characters are messed up and I get all box signs inside alert box.The same problem occurs for ToolTips as well. Any solutions?
Check your page encodings
FF uses UTF-8 page Encoding. View--> Character Encodings
Earlier versions of IE set character encoding according to the language on the client when the document did not specify encoding
Which IE Version are you using ?
This may help also. IE uses the wrong character set when it renders an HTML page
Is charset is utf in headers ?
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
I did found a solution for my query. Actually the issues were with the tool tips and alert boxes were getting displayed in box sign characters only in Internet Explorer and that too in Windows Xp but working properly in windows 7 and other browsers.
What i did was:
1. Right Click On Desktop
2. Properties
3. Appearence Tab
4. Click On Advanced Button
5. In the Item Combo box Select MessageBox(the font combo box should get enabled by then)
6. Select Arial MS Unicode Font instead of Tahoma(Windows XP Default) Font.
And then Check. The desired output will be seen. This is a work around solution but it seems to work fine. Thanks WouterH and Hardik for your guidance till here.
Here's my JS insert:
<script type="text/javascript" src="include/profile.js"></script>
In IE8 with "Compatibility View," the file never loads. The first line in the file is a simple alert() call, so that I know it loaded. Change the browser to Standards View, and it loads fine.
Also, if I add:
<meta http-equiv="X-UA-Compatible" content="IE=100" >
It forces to Standards View and it loads fine.
Any idea why this would be the case? I've not been able to test against IE7, but I know the JS file also does not load in IE6.
Right now the tag is in the section of the file.
It would seem that IE8, Safari, Firefox, et al will tolerate certain JavaScript syntax errors. IE7 and IE6 (and IE8 in 'compatibility view') will not, and they will also not throw a parse error or any other kind of clue.
Pasting my code into http://www.jslint.com/ revealed a couple of syntax errors that weren't affecting the code's operation in other browsers. So boo on me.
Okay. Had the same problem on IE8 and safari 5 on windows and finally got this working. This one is really beauty...
I had a function with a parameter named 'class' which was causing the issue. Renaming to clsname fixed the problem. Apparently FF and chrome were lenient about this.
Turn on script debugging and see if you are getting a javascript error in compatibility mode. The presence of an error would keep the javascript from executing even if it is loaded. You might also want to use the developer tools in IE8 to debug the javascript and/or verify if the file is loaded or not.
just spent couple of hours on this - IE7 & 8 suffers from "return" identificator
I had:
m["return"] = 123;
var x = m.return; // SILENT ERROR!
Obviously, renamaing identificator solves this