I see nothing wrong with the page. It is correctly marked as UTF-8 by both a Content-Type: header which appears both in the HTTP response and a <meta http-equiv> tag.
It contains the byte sequence e2 82 ac to represent the € sign, which is correct.
Firefox claims to be rendering it as UTF-8, which ought to be correct. And yet firefox is still showing me a ¤ sign.
If I tell Firefox to render it as ISO8859-1, it shows â‚¬ instead. And I switch back to UTF-8 and it shows ¤ again.
Strangely, when I *select* the ¤ sign in that tab and paste it here, it pastes as €. So could it just be a *font* problem?
Created attachment 482622 [details]
screenshot of non-reproduction
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
I cannot reproduce here with firefox-3.6.14-1.fc14 (see the attached screenshot). So, we need more information to be able to reproduce the issue here.
1) Are you able to reproduce this when running firefox in the safe mode (i.e.,
run it with parameter -safe-mode on the command line)
2) Are you able to reproduce the problem with the upstream binary from
3) Are you able to reproduce the problem with a fresh profile?
4) What fonts do you have set up for Firefox? (check for other encodings as well, particularly for UTF-8, which seems to be declared encoding of the page in question)
5) We would need to understand more about fonts on your system. Could you run the attached script on your system, please, and paste here the result?
Thank you for your cooperation and helping to make Fedora more awesome!
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 482624 [details]
test script to investigate fonts
Could I get also a screenshot of Edit/Preferences/Content/Advanced, please?
(In reply to comment #2)
> Created attachment 482624 [details]
> test script to investigate fonts
Serif: DejaVuSerif.ttf: "DejaVu Serif" "Book"
Sans Serif: DejaVuSans.ttf: "DejaVu Sans" "Book"
Lucida Grande: DejaVuSans.ttf: "DejaVu Sans" "Book"
Lucida Sans Unicode: lsansuni.ttf: "Lucida Sans Unicode" "normal"
Helvetica: n019003l.pfb: "Nimbus Sans L" "Regular"
Arial: arial.ttf: "Arial" "Normal"
Verdana: verdana.ttf: "Verdana" "Normal"
sans-serif: DejaVuSans.ttf: "DejaVu Sans" "Book"
Created attachment 482666 [details]
Advanced content prefs
If I uncheck 'Allow pages to choose their own fonts, instead of my selections above', then the problem goes away.
Created attachment 482669 [details]
output of 'otfdump lsansuni.ttf'.
If I use firebug and remove 'Lucida Sans Unicode' from the CSS list of fonts, then I get the € character back.
Is this a fontconfig problem, or is the font just buggered? I can provide the actual .ttf file if necessary; here's the 'otfdump' output.
Looks like this font doesn't *have* a glyph for code point 0x20ac. That would make it a code bug, right?
(In reply to comment #8)
> Looks like this font doesn't *have* a glyph for code point 0x20ac. That would
> make it a code bug, right?
yup ... I thought so ... some replacement rule had to kick in, because ¤ used to be a generic monetary sign, so when Firefox didn't find €, it tried the second best thing apparently (which is I guess correct on FF side, although the result is disappointing).
Although, an interesting question is why it didn't go after "Lucida Grande" when it has one and it is first. But that would be a question for pango folks. I think, nothing for Firefox here.
So, the question is ... what is lsansuni.ttf about, and where does it come from?
And the second question is ... should I reassign this to pango, or to whichever package lsansuni.ttf comes from?
Reassigning to fontconfig and asking mkasik for help.
Could we get that font as well attached to this bug (as a private attachment, so we won't distribute it worldwide), please?
Created attachment 482799 [details]
This is the font. I don't see how to make it private; could you do that please?
It's from a font CD I bought some time ago; it's not something we're distributing in Fedora.
I had a look at the problem but I haven't found its root yet. I'll investigate it in more detail later.
Can someone give me perms to download the font?
(In reply to comment #0)
> Strangely, when I *select* the ¤ sign in that tab and paste it here, it pastes
> as €. So could it just be a *font* problem?
It is very possible it is a font *and* software problem (just look at that font in gucharmap to check if the glyph is there or not, right click on it to make sure it comes from the font you expect)
In the early days of €:
1. a lot of fonts didn't include this sign, so some apps may have coded private fallbacks to other symbols (instead of relying on fontconfig because "it's not available in windows", sigh)
2. people expected € to replace ¤, because ¤ was already printed on western keyboards, not hugely useful, and in an 8-bit encoding (non unicode) world adding a new sign required dumping another. That's what happened in iso-8851-15, but because US people refused to make iso-8851-15 their encoding default instead of iso-8851-1 (as was expected by Europeans), iso-8851-15 is largely stillborn and less supported than UTF-8. And saner people put € on altgr+E instead of the badly placed key ¤ was relagated at (we may still have a few legacy xkeyboard-config layouts that put € at ¤).
1. if the font is missing €, its author should add it (but no chance in hell for that to happen in a freely distributable closed font)
2. if fontconfig or firefox still contains code to substitute ¤ to € it should be removed. With so many fonts including € this code is way past its due date
make it iso-8859 here (cut and paste strikes again :()
Apparently the Apple Roman encoding was changed to substitute the Euro sign instead of the currency sign. That happened in Mac OS 8.5. So, we can call this a legacy-font bug I guess. See:
In fact, fontconfig has code to prefer Unicode cmap over Apple Roman cmap if the EURO SIGN is covered by the font. That logic however is failing because indeed the Unicode cmap doesn't cover Euro.
It may be time to simply remove the Apple Roman decoding from fontconfig. Filed:
*** Bug 698601 has been marked as a duplicate of this bug. ***
*** Bug 698599 has been marked as a duplicate of this bug. ***
fontconfig-2.8.0-6.fc17 has been submitted as an update for Fedora 17.
fontconfig-2.8.0-6.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Installing this package on F16 fixes the issue with www.apple.com for me too; thanks.