So have a very strange issue in firefox with font-face. I've included all the different font version types (.ttf, .woff, etc.) but don't see it loading in the browser (works fine in chrome). However, when I inspect it with firebug and hover over the font name in the inspector, it previews it correctly. So it is loading the font somewhat, but not in the main browser window. Anyone seen this before?
It ended up being that if font-family has spaces in it you need to surround it with double quotes not single :P
Wild guess: do you use NoScript? It blocks downloaded fonts by default. (Rationale is that font engines weren't necessarily designed for arbitrary input and may be just as vulnerable to attack as anything else.)
Related
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.
Probably a weird question and after your answers I might be ashamed for asking this.
I have a specific font embedded on my website (via #font-face) this font is used for a section that is only visible on wider resolutions (desktops). On Smartphones for example, this section is not visible (display:none).
The #font-face rule is not defined within a media-query but right at the beginning of my stylesheet.
I wonder now if it would be possible to avoid loading this embedded font-file if I'm viewing the site on a mobile device.
You know. The font-file has a view kb and I want my site to be as fast as possible. Since the font wouldn't even be needed on my mobile version I wonder if
1.) the font is even loaded at the moment? I have no idea how to test this on my iPhone. Since the section where it is used is set to display:none I don't get any feedback.
2.) If it is loaded (and I guess so) would it be possible to set this #font-face declaration inside a media-query with max-width : 640px (e.g. iPhone) and the files wouldn't be loaded in this case?
Any ideas on that matter?
thank you in advance.
1) Images with display:none are loaded in some browsers and in some others not. So i guess it's the same for fonts.
2) There is a bug in FF 3.6, but they probably have fixed it nowadays. As far as i know, browsers supporting both media-queries and #ff should render it correctly.
CSS standards dictate that At-rules inside #media are invalid in CSS2.1, but according to this post you can load an external file with #import and a media-target declaration, i guess this way:
#import url("fonts.css") screen and (min-width:800px);
But you know, #import doesn't work that well. So i just wouldn't care about CSS2 and pretend to be writing CSS3 ;-)
This guy says that it's ok to just move #ff inside a media query.
I believe the best solution is to put it inside a min-width media query (don't forget to use the only keyword, which is intended to hide media queries from older browsers).
Using min-width is definitely more suitable than max-width for a progressive enhancement approach, and if your site is designed for mobile devices too it's probably what you want to use.
But as others said, testing is a must-do ... and sharing the results too ;-)
It seems to work. Didn't test it in older Versions of IE (I'm using modernizr, etc. for media-query support in older brosers) but it might work.
I'm defining the #font-face rule directly inside the mediaquery where it is needed. I tested it with all modern browsers. There is no request if the browser window is very small and the media-query isn't triggered. Once I resize the window to a larger with (where I need the font) it is loaded.
Just what I wanted.
I am using Windows 7 and Google Chrome and I can see all these icons:
★ ♥ ♠ ✈
☺ ☻ ♫ ♪
✔ ✖ ♂ ♀
☢ ✡ ☞ ☯
But when I try to rename a bookmark in Google Chrome this icon works: ♥
but this not: ★
Instead of displaying the star, I just see a longish rectangle:
Does anybody knows why?
The font used in the GUI does not contain this glyph, so it just displays a placeholder.
My guess is that's because there are 110,000 characters in the Unicode standard and all fonts have varying coverage of it.
For example Arial Unicode MS covers just 38,917.
To make sure if that's the case you could find out what your Windows uses as a system font to display folder names (or is it Chrome folders on your screenshot? then finding out the font used could be harder) and try to set it as a font that your browser displays pages with.
As your comment to the other answer shows you've succeeded in proving my guess, congrats!
I'm having troubles figuring out why Chrome and Firefox are rendering some things differently. Below are images of a part of my project as seen in Firefox (top) and Chrome (bottom). MathJax renders everything as the page is loading and once everything has been processed and typeset, it is displayed on the page. So I'm not sure if this is my fault of MathJax's fault. Anyway here are the images...
... if you would notice, the square with black border is different in Chrome, and in a bad way. Any ideas as to why this might be happening? The following is output from Chrome's console...
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Regular.svg#MathJax_Main-Regular:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Bold.svg#MathJax_Main-Bold:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Italic.svg#MathJax_Main-Italic:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Math-Italic.svg#MathJax_Math-Italic:-1
etc...
The code for rendering the square alone, without all the other fancy stuff, is relatively simple...
<div id="square">
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<mo id="tag0" class="expand">◻</mo>
</math>
</div>
... and then I tell MathJax to render it...
MathJax.Hub.Queue(["Typeset", MathJax.Hub, "square"]);
... and MathJax does its thing (I have no control over the rendering MathJax does). So I don't quite know where the problem is.
I know this is a very strange and very specific question but I'm hoping someone in the Stack Overflow community might have some idea or has dealt with MathJax previously. Hopefully some brainstorming will help resolve this issue.
The box you are seeing Chrome is the "missing character" symbol. The MathJax fonts don't include U+25FB, and so Chrome is showing the missing symbol. It looks like Firefox is finding the character in a different font and using that (or perhaps you have STIX fonts on the machine running Firefox but not the one running Chrome, and MathJax is using that). Browsers differ in their ability to find alternative fonts for symbols that aren't in the MathJax fonts.
In any case, try using U+25A1 instead of U+25FB and see if that works better for you.
Davide
MathML will come to Chrome natively, WebKit has been working on it for some time now:
http://www.webkit.org/projects/mathml/index.html
I guess this question should be marked as a bug for MathJax. Hopefully soon, there would be a native solution.
I do not have a real answer, however rendering differences among browsers are nothing new. I use Firefox, Chrome, Opera, IE (in that order), quite often one of the browsers renders better than the rest. Firefox has some nice debugging plugins, you may try those (Firebug???). Warning: You may spend a lot of effort on this. If you get into troubleshooting CSS, ouch :).
It only happens on some web pages, and only for some text items. On splurb.com, it is happening all over:
http://scottelkin.com/images/splurb.jpg
Going to splurb.com it looks like the font used is in the family of Helvetica,Arial,sans-serif(lifted from the css). Those fonts should be included into windows. Perhaps they have been removed. Make sure those fonts are installed.