Closed Bug 90643 Opened 23 years ago Closed 23 years ago

Does not render symbol font as commanded by CSS

Categories

(Core :: Layout, defect)

x86
Windows 98
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: ra.jones, Assigned: clayton)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001062815 The HTML <span style="font-family: symbol>m</span> should produce greek 'mu' character but does not. Similarly using <span class="symbol"> and defining 'symbol' in linked style-sheet also ignored. Also does not render symbol font using <font face="symbol"> command. Seems that browser cannot handle symbol font. Reproducible: Always Steps to Reproduce: 1. Look at any page with symbol fonts specified: try http://www.hmds.org.uk/pcr.shtml - scroll down to 'T-cell receptor (TCR) gene rearrangement studies in lymphoproliferative disorders' 2. Dispair 3. Actual Results: Displays letters in brackets as (a), (b), (g), etc Expected Results: should have greek symbols in brackets
Marking INVALID. According to the CSS2 font selection algorithm (and any sensible interpretation of the HTML spec) the character "m" in the document means just that -- an "m" character. Since the symbol font doesn't have a glyph for "m", it goes to the next choice font, which, since it isn't provided, is the default font.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verf.
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
*** Bug 201387 has been marked as a duplicate of this bug. ***
Note that now <font face=""> will do the backwards compatible thing (picking the glyph from the specified font by index) and font-family will do the correct thing (picking the glyph by UNICODE codepoint).
*** Bug 212238 has been marked as a duplicate of this bug. ***
*** Bug 235466 has been marked as a duplicate of this bug. ***
*** Bug 260678 has been marked as a duplicate of this bug. ***
*** Bug 276070 has been marked as a duplicate of this bug. ***
*** Bug 278129 has been marked as a duplicate of this bug. ***
Then, how does one specify (pick) a glyph in a particular symbol font? E.g., the code Chapter One<span style="font-family: Wingdings;">&#0240;</span> explicitly requests the user agent render Wingdings' hollow, right-pointing arrowhead after the word One, by specifying the font face, then the character's codepoint (offset, dec. 240) within, but still nevertheless is rendered as eth (ð), regardless of which encoding I stipulate in FF 3 beta. In Zapf's Wingdings font (which is a plain, non-Unicode, TT font with no character sets per se, character 240 (0xF0)is the hollow right-pointing arrowhead, and explicitly specifying the font face in the stylespec and the character's offset within it should render that way, and only as eth in the default font if the user agent can't find the Wingdings (symbol) font installed in its O/S workspace, right? If there's another way to do it, please E-mail me HTML that demonstrates it. MANY authors will be wanting to use these kind of symbol-font glyphs, and the above code does work without error in MSIE 7 & 8 beta. Thank you.
This bug will cause my websites to have to suggest not using Firefox as it is necessary to use Greek symbols and the symbol font. It works in all other browsers making Firefox incompatible with all others.
See also Bug 31538 It is strange to ignore this bug. I very often get smileys from outlook users which display as "J".
Tons of bugs have been marked as a duplicate of this bug - which is classed as "invalid". Why would so many people keep complaining about something that "is invalid"? I have had this problem as long as I've used Thunderbird; I've just ignored it until now. But it is annoying. I'm the only one in my company using Thunderbird, the others use Outlook. When emailing about product specs with a certain business partner, we often reply to seperate sections of the email, and that guy always uses a → sign to show that he's replying to something right there. Those signs appear like à to me, so I just learnt to remember that à means →. ☺ shows up as J, ☹ shows up as L, etc etc. http://www.justinswan.com/damn-js-in-thunderbird-emails-smiley-faces.html describes two ways to fix the problem; I'm using the addon ("Smley Fixer 1.1") myself (since today). The page says that the problem is fixed since after Thunderbird 3, but that is not correct. I'm using Thunderbird 11. Why do I need an addon to be able to see the signs that my collegues are using in their email? Is it my fault that Outlook uses Wingdings in its emails? Who cares anyway? I just want to be able to view my emails the way my collegues meant them. Wingdings IS installed on my system. Why can't Thunderbird (and Firefox) just support it then, for those people that have it installed? Okay - I do realise there have been lengthy discussions about this in the past. If you want to keep it away from Firefox in order to strictly adhere to standards there, fine (even though Safari and Chrome do show them 'as expected'). But Outlook isn't going away, and Thunderbird users will keep getting email from people that use it. HTML email isn't very advanced anyway, so why not make this concession?
By the way, the URL on this bug is out of date. The Status and Resolution are as well ;)
You need to log in before you can comment on or make changes to this bug.