This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
UTF-8 issue in Firefox - response header overriding meta tag?
I have a jPlayer playlist that works fine in all browsers except Firefox.
The issue is with non-standard characters, i.e. characters with accents or asian characters. I have set up a demo playlist so that you can see here.
When I enter the characters in UTF-8 form (track 1 in the playlist) they work on all browsers except for Firefox, and when I enter them in ISO Latin 1 (track 2 in the playlist) they work in Firefox but no other browsers.
So, for instance in Firefox 大å°æ¸æ¿.mp3 works, whereas 大地書房.mp3 doesn't.
When I use 大地書房.mp3 in the Firebug console I see the following error:
"NetworkError: 404 Not Found - http://monthlymixup.com/mixups/july_2012/media/simon/03%20????.mp3"
So, for some reason 大地書房.mp3 becomes %20????. When I inspect the page the link to the audio file shows as 大地書房.mp3 though.
There is a meta tag for UTF-8 on the demo page, i.e. <meta charset=utf-8 />
My understanding is that Firefox overwrites this with the response header if a default encoding isn't set in FF. I have however set UTF-8 to be the default encoder and I have checked that the page is using UTF-8 by going to Tools/Page Info (I am on a Mac and I believe this is the way to check the encoding on the page).
So, I'm at a loss as to what is going on, and would be glad of some help.
This seems to be an encoding issue in jQuery or other software used. The entry 2 is in an odd format: looking at the source as UTF-8, I see
mp3:"media/nick/Guessi-Guéré-Guessi (Pop Bariba).mp3"
This means that the letter “é” has been represented in UTF-8, as two octets, and then these octets have been interpreted as if they were ISO-8859-1 encoded, and the resulting characters have been UTF-8 encoded. Presumably the software deals with the mess by performing the opposite double decoding. In any case, it does not work with
mp3:"media/simon/03 大地書房.mp3"
which is just UTF-8 encoded.
It puzzles me how it works on any browser, but presumably the code is browser-dependent.
The software should be changed to deal with UTF-8 as such and pass it forward, if possible. All modern browsers, including Firefox, can then deal with it properly.
As a quick fix, though, you might try to use a percent-encoded form (see e.g. online percent-encoder):
mp3: "media/simon/03%20%E5%A4%A7%E5%9C%B0%E6%9B%B8%E6%88%BF.mp3"
But this is just a guess; the software might munge this, percent-encoding the “%” sign.
Related
I have an app that uses AngularJS along with angular-translate to provide localization. The app currently uses only English and German.
On the login page is a required field, an email. If there is an error, the app displays "A valid email is required" in English.
In German (and forgive me if this is mangled, this is Google Translate, I don't know any German) the phrase is "Eine gültige E-Mail erforderlich".
In the second word, you'll notice an international character, it looks like a "u" with two little dots over it. When the app is set to display in German, that character gets escaped and much weirdness happens on the screen.
Looking that the docs, it seems like using $translateProvider.useSanitizeValueStrategy() is supposed to handle this, but it's not. If I use $translateProvider.useSanitizeValueStrategy('escaped') then it look like this onscreen:
If use $translateProvider.useSanitizeValueStrategy('sanitize')(which I'd really prefer of course) then it looks like this:
I also happened to come across this article which states that my *.js translation file needs to be UTF-8 encoded. I opened up that file in NotePad++, changed the encoding to UTF-8 Without BOM and saved it, but I'm still seeing the error. And VS really hates the file now.
I know, it's a little late, but maybe others have similar Problems:
Adressing the UI:
Are you using the attribute style e.g.
<span translate="key"><span>
or inline style
<span>{{key | translate}}</span>
in your view?
I am working with the second style without issues.
Addressing your Problem with UTF-8:
I am not using Visual Studio nor Notepad++, so I don't know how Notepad++ handles the conversion. Possibly it does not convert the characters at all, but only changes the file to be seen as UTF-8.
Sublime Text 2 (1), on the other hand, offers you to 'Save with Encoding', which converts all characters accordingly. I stressed this conversion pretty much, so that I can recommend this approach with a clean conscience.
(1) I have no relations to Sublime Text, this is not meant be any form of commercial advertisement
Most of the monospace fonts normally used for programming on Windows (all I have found so far) don't display 'funny quotes' (0xE2) properly. For example, an error message from the gcc compiler like
warning: conflicting types for built-in function âprintfâ
which is really
{funny quote}fname{funnyquote}
displays in Ludida Console, DejaVu, etc. as
{circumflex a}fname{circumflex a}
(It may be doing so for you right now). Is there a a helvetica-like monospace font that respects that particular 8-bit codepage?
Windows has a split personality. Most of it is based on Unicode, while some parts still rely on code page character translations.
The character you're getting for 0xE2 is the proper Unicode translation, and is the same in the very common code page 1252 and most of the rest as well. The only code page that has a quote for that value is code page 10000, Mac OS Roman.
The chcp command is used to change the code page of the command window, but I can't get it to work for your specific case.
Take a look at this:
http://thebekker.dk/_skole/GFeksamen/
You can see the 2nd menu item show some weird sign, instead of "Ø"
Ive set utf-8 in meta, and even tryed with AddDefaultCharset UTF-8 in .htaccess...
Still no result, if i change to ISO-8859-1 which works fine, but that makes problem when i start making ajax calls for content...
I dont get it?
How do i get it to use UTF-8 and show ÆØÅ
If you declare that your content is encoded in UTF-8 with the meta tags or default charset, then your content needs to be actually encoded in UTF-8. The fact that it shows correctly when declaring your content to be encoded in ISO-8859 means that your content is actually encoded in ISO-8859. Save your source code file as UTF-8 or otherwise make sure that your content is UTF-8 encoded.
Saving the source file in "Western European (Windows)" in EditPlus text editor did it for me + in PHP I used utf8_encode.
you can set this characters with unicode like € or so many others. In my company we work with many translations and languages like france, that has many special chars.
set your website encoding type to utf-8 and use encodings like utf8_encode in php
or manually: http://www.sql-und-xml.de/unicode-database/online-tools/
I have Museo-300 mostly working with #font-face, but certain letter combinations like "ff" and "fi" are disappearing in Firefox (confirmed in v3.6 and v7.0.1). So "microfinance" becomes "micronance".
Note that I'm outputting these as individual letters, not as ligatures. When I view source on both the server and the browser, "coffee" for example is spelled with all six letters individually—not a unicode ligature character for "ff".
The output looks right in Opera, Chrome, Safari, and IE (even IE6).
I downloaded Museo-300 from MyFonts along with their web font example template.
#font-face {
font-family: 'Museo-300';
src: url('webfonts/151B6C_0.eot');
src: url('webfonts/151B6C_0.eot?#iefix') format('embedded-opentype'),url('webfonts/151B6C_0.woff') format('woff'),url('webfonts/151B6C_0.ttf') format('truetype'),url('webfonts/151B6C_0.svg#wf') format('svg');
}
and all the referenced files are in place. I invoke it like this:
font-family: 'Museo-300', sans-serif;
I tried a different font as a test (Code Pro Light Demo, also gotten from MyFonts) and Firefox dropps "fi" but not "ff" for that one.
An idea what's going wrong?
For anyone reading this in the future, note that as of FF 15 (I think) the syntax has now changed, and you'll need to use this:
-moz-font-feature-settings: "liga=0";
-moz-font-feature-settings: "liga" 0;
You can tell Firefox to skip looking for ligatures and treat them as regular characters by adding
-moz-font-feature-settings: "liga=0" in your font-face declaration.
In case others hit this problem, I resolved it with help from MyFonts technical support. I'm not sure whether this issues is specific to MyFonts, but I suspect it affects other web font sources.
Direct (Solvable) Cause
When a standard True Type font (TTF) gets processed into the multiple versions that are useful for a web font (EOT, SVG, WOFF), the processing tool or vendor can decide whether or not to include the font's full character set. Some will default to a reduced character set to reduce file sizes.
In my case, one or more of the generated web font files excluded ligatures, presumably considering them to be non-essential typographic tweaks. To fix the problem I used a custom web font builder at MyFonts to generate font files with the full character set.
(For MyFonts specifically this was at Order History > select relevant font > Webfont Kit Builder tab > Advanced, then check both "Complete Character Set" and "Keep OpenType Layout".)
Underlying Cause
My belief, which is only an educated guess:
I think Firefox is going out of its way to do nice typography, more so than other browsers. So when it sees something that it could render as a ligature ("fi", "fl", "ff", etc.) it tries to render the letters as a single ligature glyph rather than as two distinct characters. If your web font doesn't include the ligature glyphs, your letters will disappear. (If my guess is right, I'm surprised I haven't read about this problem before.)
Myfonts.com recently changed some display settings. Their support wrote back very quickly with the following info:
If you click on the Font image (the image that shows the sample),
which is located right above Kit Options, you will see the Complete
Character set and Keep OpenType Layout options.
This view is not currently available through Firefox though, but I was able to download the complete character sets using IE9.
I'm trying to find a way to make dingbats appear exactly the same in Firefox, Chrome, Safari and IE.
I noticed that the Dingbats appear the same in IE/Chrome/Safari, HOWEVER - in Firefox - they look "thinner".
For example - try to visit the following page:
http://en.wikipedia.org/wiki/Dingbat
You'll notice that when viewing that page in Firefox - the characters look different in comparison to Chrome/IE.
Does anybody know why and how can I cause Firefox to display the characters EXACTLY like they appear in Chrome/IE?
I'm trying to find a way to make dingbats appear exactly the same
You will never make fonts look exactly the same in all browsers, whether the characters in question are Dingbats or not.
For me, most of the characters on that page don't render in IE or WebKit. IE traditionally has poorer font fallback than average and Firefox typically better then average. The font that Firefox and Opera manage to choose to render the symbols for me is Meiryo (a Japanese font installed with Windows Vista and later). On IE and WebKit it falls back to the much more limited selection of symbols available in Arial, leaving most of the characters missing.
So for the best chance of rendering symbol characters how you want, do as you do for any other characters, and specify the font you want, eg. CSS font-family: Meiryo. But of course anyone who doesn't have that font installed will get something different, and browser/OS settings may change how fonts are rendered in general.
The symbol characters from the Zapf Dingbats set are not safe to use on the web, as the basic default sets of fonts installed by operating systems do not typically include glyphs for most of them. (‘Wingdings’ on Windows does, but it's a legacy font with a custom mapping that puts the symbols on ASCII characters instead of where they should be in Unicode, so again it's not safe to use on the web.)
There are a few symbol characters that you can typically get away with using for commonly-available font sets, eg:
● ■ ☺ ☻ ♥ ♦ ♣ ♠ • ▲ ▼
others, I'd try to avoid.
Interesting...On a MacOS X 10.6.6 machine with Firefox 3.6.13 and Chrome 8.0.552.231, the Wikipedia pages do render the first table, the ITC Zapf Dingbats, slightly differently. The effect is most noticeable on the solid half-circle at the bottom left corner of the set of characters.
The main Unicode Dingbats table renders almost the same; Firefox generates boxes containing the 4 hex digits of the missing character for the missing symbols, but Chrome just generates empty boxes - I prefer Firefox's technique.
The browsers must either be using slightly different fonts or slightly different font sizes (though I can't detect a size difference by eye). I've not looked at the HTML that is being rendered.
On the whole, I think that this is within the realm of 'allowable variation' - but I'm not an expert. I suspect you have a world of worry ahead of you if you demand pixel-for-pixel similarity between browsers. The concern should be to get the message across clearly.