Closed Bug 33127 Opened 24 years ago Closed 17 years ago

<font face="symbol"> not working on Windows (not a bug per UNICODE, TrueType, XML, CSS, XHTML and HTML specs)

Categories

(Core :: CSS Parsing and Computation, defect, P3)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: gerv, Assigned: dbaron)

References

()

Details

(Keywords: compat, Whiteboard: either INVALID or see comment 119)

Attachments

(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (Win95; U)
BuildID:    20000323

On other platforms, and in NS 4.7 on Windows, the word on the pink background in 
the test URL (from the Browser smoketests) is in Greek characters, because the 
font is Symbol. In Mozilla, it's in normal characters. Mozilla isn't picking up 
the Symbol font.

Reproducible: Always
Steps to Reproduce: Go to URL. Look.

This is probably a dupe of one of the numerous bugs to do with fonts...
Dup of bug 22031 "'MS Sans Serif' (+ other fonts) not recognized on WinNT".


*** This bug has been marked as a duplicate of 22031 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
If this is a dupe of that bug, can it be changed to have a more descriptive 
title, then, please? :-) I did not see this on NT...

Gerv
No, the test URL has the word "Opaque", which is in normal English letters, and
should not be rendered with the Greek glyphs found in the Symbol font. This is
actually a bug in Nav4, and Mozilla is correctly rendering the word Opaque as
Opaque instead of Greek gibberish. Reopening so that I can mark it INVALID.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
Marking INVALID. See previous comment.
So if Mozilla renders this in Greek letters on any platform, that is a bug? 
Because I seem to remember my Mac smoketesters saw it in Greek. Let me know and 
I'll open a new bug for that problem.

Gerv
MathML doesn't work yet on the Mac because GetBoundingMetrics() is not
yet ported on that platform.

There shouldn't been greek letters. The rendering of
<font face="symbol">Opaque</font> should give the word "Opaque" on all 
platforms. This is the correct behavior I see on Windows. If it is not
the behavior observed on the Mac then there is a bug on that platform.
Adding 'verifyme' keyword
Keywords: verifyme
*** Bug 49594 has been marked as a duplicate of this bug. ***
Works for Me Mozilla renders it correctly.
Platform: PC
OS: Windows 98
Build # 2000100508 M18 Trunk Build
Marking as Verified
Status: RESOLVED → VERIFIED
Does this apply to characters > 127?
Jesse, this applies to all characters.
Is there a way to code the greek letters and/or mathematical symbols from the 
Symbol font that works on Netscape 4, IE, and Mozilla?  Or are people stuck 
choosing font face vs. numerical or descriptive entities depending on which 
browsers are most important to support?

Is there a Netscape or Mozilla page that describes what various browsers 
support and suggests possible solutions (like Eric Krock's page for DOM)?
Erik - this does beg the question "How does one actually use Symbol font"?

Gerv
In Mozilla, you can use the "Symbol" font if you code the text appropriately,
e.g. a Greek charset, or Greek entities such as &alpha;.

I don't know whether these work in IE and Nav4. If this turns out to be
important in the marketplace, I'm sure we'll find out, and then we can add some
sort of hack to Mozilla to be compatible with the buggy past.
*** Bug 34940 has been marked as a duplicate of this bug. ***
*** Bug 62234 has been marked as a duplicate of this bug. ***
The symbol font is essential to scientists! Fix this ASAP.
It's not a bug!  Fix your HTML ASAP.

More seriously, though, breaking with this broken behavior of Nav4 allows much
more reliable, cross-platform, description of special characters, since you
don't need to depend on somebody else having the same font for those characters
as you do.  "Fixing" this would be a bad idea (unless we want to promote a
Windows-only web), although the transition to correct HTML may be painful at times.
*** Bug 66333 has been marked as a duplicate of this bug. ***
*** Bug 75387 has been marked as a duplicate of this bug. ***
Keywords: verifyme
The lack of support for font changes (to symbol) is a critical issue. I have 
looked hard, and there is no way of making a page with Greek characters that 
will work in IE, Mozilla and NMetscape 4.7x.

In addition, tools such as WebWorks that convert Framemaker to html also fail to 
make pages that display in Mozilla. 

The unicode set does NOT include ALL of the symbols in the symbol font.

And my large collection of Adobe fonts do not include the Unicode characters.

It is now impossible to use Mozilla for everyday browsing.
Will the following work?
<font face="xyz"> ...
when browser encounter this, it looks up a table specified by user and
finds an entry called "xyz, myFont.font" and display the fonts using
the specified font file.  Mozilla can come with predefined font face
"symbol" and a couple of others that often used, while leaving the option
open for future.

I'm no specialist at issues of browser, and am not sure the idea would
be feasable or not.

Thanks.
James: There are many ways of creating web pages that display greek characters.
One is to use ISO-8859-7 as the character encoding. Another is to use UTF-8 and
embed the Greek characters. Another is HTML character escapes.

> The unicode set does NOT include ALL of the symbols in the symbol font.
That's a problem for you to take up with the UNICODE consortium. (It also
surprises me a little. Which characters did you have in mind?)

> And my large collection of Adobe fonts do not include the Unicode characters.
That's an issue for you to take up with Adobe.
ekrock/hixie: what do you think of linking from 
http://sites.netscape.net/ekrockhome/standards.html to 
http://www.hclrss.demon.co.uk/demos/symbol.html (or to another page describing 
how to fix pages that use the symbol font)?
Well, the following does not work in Netscape 4.77
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="James A. Rome">
   <meta name="GENERATOR" content="Mozilla/4.77 [en] (Windows NT 5.0; U) 
[Netscape]">
   <title>test</title>
</head>

<body>
&beta; is a Greek beta or &#946; in unicode
&lang; is a left angle bracket or &#9001; in unicode
</body>
</html>
*** Bug 78929 has been marked as a duplicate of this bug. ***
See also bug 77265, "Wingding symbol font not rendering in Mail".
*** Bug 99268 has been marked as a duplicate of this bug. ***
*** Bug 100621 has been marked as a duplicate of this bug. ***
*** Bug 101405 has been marked as a duplicate of this bug. ***
I feel it is extremely ignorant to say "fix your html" if scientific texts
need the symbol font! In particular, since there is no other way to
get greek letters, scientific symbols, etc. This is just like saying "We don't 
give a damn about scientists, they should get a copy of IE instead". Is this
what you want us to do?
>I feel it is extremely ignorant to say "fix your html"

So how does one get a Greek character into HTML which is compatible with BOTH 
Netscape 4.76, v6.1, and MS Internet Explorer 5.5?

The use if <font face="symbol"> may not be strict, but it works, and it is 
intuitive.

And IF it was implemented, what harm would be done? What's the disadvantage of 
<font face="symbol">a</a> displaying <alpha> instead of the letter 'a'?

Regards,
Ian
More to the point, not all the characters in the symbol set are available in
Unicode. And there is no support for unicode conversion of math symbols in the
tools that I use (FrameMaker->WebWorks).

The other browsers do not support Unicode.
Gerald, Ian & James: it is necessary for internationalization and standard-
compliance issues that browsers stop considering ASCII characters as numeric 
values that can be used as offsets in a font table.  An 'a' is an 'a', it's not 
97.  If we don't do it, we'll continue to plague people across the world with 
problems everytime they want to mix characters from different origins.

Using the Symbol font this way never really worked anyway, or maybe just on a 
particular platform or with a particular set of characters.  See 
http://www.hclrss.demon.co.uk/demos/symbol.html for more info.

> So how does one get a Greek character into HTML which is compatible with BOTH 
> Netscape 4.76, v6.1, and MS Internet Explorer 5.5?

You can use UTF-8.  See for instance http://www.columbia.edu/kermit/utf8.html: it 
displays characters of many origins within a single document (including greek 
characters).
UTF8 does NOT have all the characters in the symbol set. That is the problem.

http://www.hclrss.demon.co.uk/unicode/mathematical_operators.html
does not display properly on IE6 or Netscape 4.77... So much for standards.

90% of the world's PCs use Windoze. Most people use IE. I would rather my Web
pages displayed properly on 90% of the browsers than on just Mozilla.

Which characters does Unicode not have?  (Unicode is a character set; UTF-8 is a
character encoding capable of encoding any character in Unicode.)

You can also use &alpha;.
CCd ftang who, wrong or right, seems enclined to look at another strategy under 
bug 104531.
IE's online help knowledge base does not have ANY references to Unicode or ISO
10646.

The &alpha; notation works for some things, but leaves out a lot of things like -/+.

It is essential that exports from programs like Word and FrameMaker create html
that can be read in Mozilla. Look at my hairy Stellarator News in PDF and HTML
http://www.ornl.gov/fed/stelnews
I worked really hard to get WebWorks to make html that worked everywhere, but
failed. If I want to reach the largest audience, which browser do you think I
must support first?
Moreover the &alpha; thing does not work with older browsers and it does
not work with mozilla!? At least on my Mac (OS 9.2) any page containing
&alpha; will crash mozilla 0.95 on the spot;-(
*** Bug 104531 has been marked as a duplicate of this bug. ***
Reopening and CCd other folks in Layout, CSS and e12n...

IanH, DBaron, FTang: I think we should consider implementing this as a Nav4 quirk 
on all platforms when the font-family is (or contains the word) "Symbol", 
"Webdings" or "Wingdings".  We implemented it for Webdings and Wingdings on 
Windows only (see bug 94319 about the "fontEncoding.properties" file).  Why 
wasn't it done on all platforms?  Why don't we do it for Symbol too?

The main reasons for raising the issue again are:
- Compatibility with existing browsers is becoming increasingly important for 
products that embed the layout engine (some bugscape bugs were filed on that 
matter).
- Unicode doesn't provide all the glyphs in these fonts.
- We've got many dups here, and in bug 31538 too.  We have to acknowledge the 
convenience of the mapping between western and greek alphabets offered by the 
Symbol font.  After all, it works in all the main browsers.
Severity: normal → major
Status: VERIFIED → REOPENED
OS: Windows 95 → All
Hardware: PC → All
Resolution: INVALID → ---
Target Milestone: --- → mozilla1.0
> This is just like saying "We don't give a damn about scientists"

I *am* a scientist. (A physicist undergraduate.)

Tim Berners Lee, who originally invented HTML and who founded and is currently
the leader of the World Wide Web Consortium, which fully backs the use of
UNICODE and is against the abuse of the Symbol font, was a physicist who worked
at CERN, one of the leading centers for scientists worldwide.

I most certainly DO give a damn about scientists. However, I have to stand up 
and ask my colleagues to follow the standards and not continue using outdated
hacks and workarounds for old browsers.


> - Unicode doesn't provide all the glyphs in these fonts.

Which characters of the 200 or so Symbol font glyphs are missing from the over
16000 UNICODE characters?


This bug is invalid. If we change our handling here we are going to end up 
going down a slippery slope where we no longer care about standards. Changing
summary to more accurately reflect the so called "bug" here.
Keywords: compat
Summary: <font face="symbol"> not working on Windows → <font face="symbol"> working per spec on Windows
Whiteboard: INVALID/WONTFIX
Since we now deal with historical matters, just another hint about TBL  :
during the WWW conf in Paris (1996), TBL gave a talk about URNs, you know the
things that were about to replace URLs everywhere and make us use names instead
of adresses. I asked TBL during a short and private discussion, after the talk,
"what about now ? we cannot wait until URNs appear and the Web needs I18N... It's
a totally normal request for a japanese to be able to write a web coordinate
using japanese characters. We need Unicode in URLs". He answered "Me alive,
never!".

Standards are an answer ; not the answer. Standards can be wrong, can be useless,
can unsuccessful, can be obsolete. Standards are just made by human beings
dreaming of a perfect world, don't forget it. The world, and in particular the
Web world, is not perfect.

Sorry for the digression, I just wanted to remind you that, sometimes, 
saying "no" to the rest of the world just because of a standard can be counter-
productive.

For the time being, I see much more scientific docs using symbol fonts
than unicode, sorry to be strongly affirmative about it.

(btw, I studied fundamental physics too)
> Standards are an answer ; not the answer. Standards can be wrong, can be 
> useless, can unsuccessful, can be obsolete.

Thankfully, UNICODE is none of those things.


> For the time being, I see much more scientific docs using symbol fonts
> than unicode, sorry to be strongly affirmative about it.

And this will continue until such time as browsers take a stand. Should we also
implement all the bugs that Internet Explorer and Netscape 4.x have in their
CSS parser? Hell no! Why is this bug any different? It's not. The correct
behaviour (using entities or UNICODE characters inline) is supported in all
modern browsers and is what authors should be using.
The correct behaviour is not supported in all modern browsers. I have been
totally unable to get the same hairy scientific page to display in IE, Netscape
and Mozilla. That is the problem. 

Even worse, none of my tools support creating such Web pages. I make my
newsletter in FrameMaker 6.0, and it gets "published" with Web Works. FM  has NO
facility for using unicode. Only a few of the &name; entities are supported by
current (non-mozilla) browsers. just compare
http://www.hclrss.demon.co.uk/unicode/mathematical_operators.html
side-by-side in IE6, Netscape, and Mozilla. Netscape displays NONE of the
characters. IE only some of them. So your point about Unicode being suppoorted
is wrong.

I MUST use Netscape, for example, because Mozilla has not seen fit to support
S/MIME e-mail. S/MIME is a modern standard that Mozilla has not seen fit to
support. And in the present world environment it is a vital aspect too.

As a publisher of Web information, I have to cater to the market share leaders,
not some ideal.
I see. So you care exclusively about the Windows platform?
Unfortunately, Windows has by far the largest market share.

How about getting Netscape (the father of Mozilla) to issue Netscape 4.8 that
supports unicode? There is no good solution to this from my viewpoint. Thus one
is forced to pick the one that works the most.

In the words of Grace Hopper, "I like standards because there are so many of
them." They must not be the be all and end all. There is nothing wrong with
being backwards compatible also until the world catches up.
Netscape 4.7 supports the Unicode ranges for basic Greek (as well as extended 
Greek and combining diacriticals) and mathematical symbols on the Windows 
platform.  So does IE, since 4.0.  Mozilla does so for Linux, Windows, and Mac 
OS X at least so far as I've tested (thanks to a lot of recent work on fonts 
support).  Microsoft's core web fonts include all the glyphs for basic Greek; I 
haven't checked to see if the core web fonts include the glyphs for 
mathematical symbols. I have not yet found a glyph in the Symbol font that does 
not have a corresponding character in Unicode; see e.g. *The Unicode Standard 
3.0*, and *XML in a Nutshell* Ch. 32 for code charts.  

There is I suspect a bug in Netscape 4.7 which prevents it from understanding 
entities in pages which it assumes to be ISO8859-1 when the entities represent 
UTF-8 characters.  Inserting a charset meta tag indicating UTF-8 resolves this 
problem (and since the first 127 bytes of ISO8859-1 are identical to those of 
UTF-8, so long as you use entities for all non-ASCII characters it is even 
strictly adherent).  I've created two attachments proving this.

I can provide a URI for my recommendations for publishing Greek text using 
Unicode on the web, and tests of various browsers with Unicode Greek (not 
mathematical symbols) to reporter offlist (they are currently on development, 
not production server).  

+/- is in unicode: in fact, it's in ISO8859-1! &#177; As is -/+ (&#8273;). 

Please provide a list of symbol font characters which reporter believes are not 
present in Unicode.  HINT: all the Greek characters (alpha through omega, upper 
and lowercase) are. I will check them against the code charts in The Unicode 
Standard 3.0 and will provide a page on a separate site demonstrating how they 
can be encoded using Unicode so that IE 4-6, Netscape 4.5-4.78 for Windows, and 
Mozilla 20011105+ for Windows, Linux, and OS X, as well as OmniWeb for OS X can 
display them.  Note that there are a few symbols which are not covered in 
existing downloadable free fonts following the Unicode standard; this is a 
fonts problem, not a rendering problem.  Would suggest that if there are glyphs 
in Symbol font with corresponding characters in Unicode which do not display 
using the Microsoft core web fonts (excluding symbol fonts) reporter get on 
MS's back to add all the Symbol font glyphs to Times New Roman in the proper 
Unicode positions, as this would be a platform issue rather than a browser 
issue.

If this is a fonts/platform issue, is it related to the MathML lack of fonts?

[

Moreover the &alpha; thing does not work with older browsers and it does
not work with mozilla!? At least on my Mac (OS 9.2) any page containing
&alpha; will crash mozilla 0.95 on the spot;-(

]

The OS 9 browsers do not really support Unicode (none of them); so far as I 
know, only WorldScript does.  But Mozilla (thanks to one of respondents on this 
bug; thank you, Frank) does on OS X, as does OmniWeb - at least for Greek (and 
I mean ancient + modern Greek).  The &alpha; entity doesn't work in Netscape 
4.78 for Windows, true, but the corresponding numeric entity &amp;#945; does.

Gentlemen:
Frankly, I'm getting tired of all this. This is turning into some sort of
flame-war and serving no useful purpose.
None of anyone's arguments has addressed the basic issue that this particular
font does not display properly, i.e., according to the specifications of whoever
designed it.
I've heard arguments about the Symbol font not having an "A", and being
otherwise a glitch in it's own right. I don't understand any of that, because it
does not match any of my own observations.
Only three facts remain:
1) Every other program on my Mac, whether it's a browser, word processor, or
graphics application, recognizes this font as any other. The character at
ISO-Latin-1 position #97 happens to look like a lowercase Greek alpha in this
font. (In Wingdings, it looks like the astrological symbol for Pisces, and it
displays properly in Mozilla.)
2) The design of any character, at any position, should be up to the font
designer, not the browser. The character at #97 is usually something
recognizable to the eye of an English-savvy human viewer as some form of a
lowercase English "a". It could look like an alpha, Pisces, or a maple leaf if
that's what the font designer has in mind. If it doesn't display properly,
because the viewer doesn't have that font, it's a problem among the viewer, the
webpage builder, and the font designer, and they can address it.
3) The designers of Mozilla have flat out refused to address this issue on the
grounds of the Symbol font's display being non-standard, despite it's (apparent)
ubiquity.
Accept it and forget it. One of two things will happen:
1) Mozilla will become a widespread browser.
 In this case, the need for straightforward display of Greek letters and
mathematical sumbols will be become strong enough for it to be addressed/fixed.
2) Mozilla will not become a widespread browser.
 In this case, the faulty display of these charcters will just be a problem for
those few users of Mozilla.

I, for one, have given up in trying to get this fixed. I'll keep my e-mail
address on the CC list in the hope that I'll learn of an eventual fix. In the
meantime, please stop the pointless bickering.
Hixie: '<font face="symbol"> working per spec on Windows' may be an accurate 
description of what's going on here, but it doesn't make this bug easy to find 
in a bug list unless you know that in this case 'working per spec' is the same 
as 'not appearing to work at all'.  I'm changing it back to '<font 
face="symbol"> not working on Windows'.  If you know what standard is involved, 
go ahead and tack on '(because moz follows the foo spec)' to the end of the 
summary, but please don't make the summary confusing just because the bug is 
invalid.
Summary: <font face="symbol"> working per spec on Windows → <font face="symbol"> not working on Windows
> The character at ISO-Latin-1 position #97 ...

Michael: I would agree with you if it wasn't for the fact that the Symbol font,
internally, claims to NOT have any character at ISO-Latin-1 position #97.


> 1) Mozilla will become a widespread browser.
> In this case, the need for straightforward display of Greek letters and
> mathematical sumbols will be become strong enough for it to be 
> addressed/fixed.

We already support a more straightforward and much more reliable display of 
Greek characters than can be achieved through the use of the hack that is the
Symbol font. Comments above indicate that this technique can be used with both
Netscape 4.x and IE (assuming bugs in Netscape 4.x are worked around in
the way also described above).

I am banking on Mozilla becoming widespread, resulting in authors being forced
to update their pages to use the standards-compliant techniques that are more
cross platform and more accessible (a legal requirement for many people now).
Summary: <font face="symbol"> not working on Windows → <font face="symbol"> not working on Windows (not a bug per UNICODE, TrueType, XML, CSS, XHTML and HTML specs)
The use of <font face="symbols"> certainly falls outside of the standards. 
There is no disagreement here. Fixing its non-standard use prevents new browsers 
from displaying non-Roman characters.

Since no-one would use <font face="symbols"> to display anything other than the 
symbol font, "fixing" it does nothing other than ensure that the standard is 
adhered to. This is the only benefit. A non-benefit.

But leaving <font face="symbols"> to display non-Roman characters ensures that 
existing HTML pages are backward compatible. That is a real tangible benefit.

And if people use <font face="symbols"> incorrectly, what is the downside? As 
far as I can see, it ONLY upsets the standard purists.

In other words, there is harm done if this "bug fix" was not fixed, and 
everything to gain.

Ian
It seems that the follows allows non-Roman characters to be displayed in MS 
Internet Explorer 5.5, Netscape 4.77 & 6.1, and Mozilla (at least on Windows 
98).

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
And then the use of entities.

For example, see the page at:
http://www.hclrss.demon.co.uk/unicode/greek.html
... which does NOT display the Greek characters on my NS 4.77. But if I save the 
file, and edit it to add the <meta> tag above, bingo!

Ian
> And if people use <font face="symbols"> incorrectly, what is the downside? As 
> far as I can see, it ONLY upsets the standard purists.

It hurts anyone without a Symbol font (the growing number of Linux users, for
instance), as well as anyone who is blind or is browsing the web via an aural
web browser (a small but growing minority). Using the symbol font also reduces
the reliability of search engines.

By forcing authors to do the right thing, Mozilla would be improving the web
overall on the long term. Yes, it may cause pain on the short term. But the long
term benefits far outway the short term loss.


Thanks for the tips on how to do this right, btw.
On what other non-Windows browsers does this symbol font trick "work"?
>It hurts anyone without a Symbol font (the growing number of Linux users
What are you talking about? It works fine under linux with some tweaking.
It does not work on my Mac....

BTW, my sentence "We don't  give a damn about scientists" just reflects
my personal feelings and this is just the impressions most others
I talked to got as well.

>Using the symbol font also reduces the reliability of search engines.
Do you *really* think mathematical formulas contain information which
are of interest to search engines.
> What are you talking about? It works fine under linux with some tweaking.

It doesn't work on my stock Mandrake 8.1 installation (there is no "Symbol"
font). And end users don't "tweak"... I thought that was the whole reason 
people didn't want to do the right thing here.


>> Using the symbol font also reduces the reliability of search engines.
> Do you *really* think mathematical formulas contain information which
> are of interest to search engines.

Not yet (see below). But the following equation:
   c &alpha; t - m &alpha; t
...wouldn't cause a search engine to think the phrase "cat-mat" was on the 
page... using the Symbol font would.

BTW: On the long term, MathML and UNICODE entities will make it possible to
search for actual equations. We have a long way to go, but this is one of the
first steps.
Hixie wrote:
> ... the Symbol font, internally, claims to NOT have any character at
ISO-Latin-1 position #97.

Normally, I'd be forced to call you either a liar or a fool; however, I can do
neither. I don't believe you're lying, and you are obviously well-acquainted
with this issue.

The fact remains that EVERY other program I have ever used, including utilities
that allow one to analyse fonts by their decimal numbers, behaves as though
there is such a character. Am I to believe that all these software manufacturers
(Microsoft, Adobe, Deneba, Macromedia, etc.) have agreed to write in hacks to
all their products to handle this one screwball font? If so, why hasn't anyone
written a replacement Symbol font that does have the desired character there?
(Maybe that's the solution.)

> We already support a more straightforward and much more reliable display of
Greek characters ...

I'm sorry, but now I must respond angrily: That's not true!
Not one, and I repeat, NOT ONE of the "solutions" I seen posted here has
succeeded in getting Mozilla (forget IE & Netscape) to display a lowercase Greek
alphabet in its entireity.
> Not one, and I repeat, NOT ONE of the "solutions" I seen posted here has
> succeeded in getting Mozilla (forget IE & Netscape) to display a lowercase 
> Greek alphabet in its entireity.

Now *that* is a bug. A separate bug. Could you file it with details of what
fonts you have on your system? Thanks!
I find it hard to believe people are still arguing for this behavior.

Examine RISKS Digest 21.68,
<http://archives.neohapsis.com/archives/risks/2001/0051.html>, and scroll down
to Rodney Polkinghorne's submission. Because font information is often lost in
automated HTML->text conversions, microns can become millimeters. Google and
other search engines will also index <font face="symbol">m</font>m as
millimeters rather than micrometers.

I also refer you to
<http://ppewww.ph.gla.ac.uk/~flavell/charset/fontface-harmful.html>, written by
a member of the Dept. of Physics and Astronomy.

In short, supporting this is positively harmful, because of the potential for
confusion and real damage that can occur during document conversion.

<http://www.hclrss.demon.co.uk/unicode/greek.html> is a fine test page for Greek
support.

Hixie: I'm not sure why you claim Symbol has no character at position #97,
unless I've tripped over a silent piece of pedantry;
<http://www.cst.cmich.edu/users/chaff1ra/webmath/fontchec.htm> has a table
showing which characters are shared between MS' Windows and Mac Symbol fonts,
and a PDF showing the complete Windows font.
(just trying to find a solution for apparently irreconcilable differences...)
How about a new menu item in "View | Character Coding" to display the way Nav and 
IE do?  A possible name could be "Non-standard".  It will let people display old 
pages while they are being converted to unicode.
I like that solution. It tried to do my last newsletter in Unicode, and all the
greek letters (&rho; ) get printed out as &rho in netscape 4.77. That is the
problem. 

http://www.ornl.gov/fed/stelnews/sn78/sn78.html

I also have been unable to find the symbol 187 (two tildes) in the Unicode math set.
James: have you tried using numeric entity references (i.e., &#961; rather than
&rho;)? I believe these are better supported than the named HTML 4 entity
references in old browsers.

The Unicode symbol you mentioned is &#8776; "ALMOST EQUAL TO".
For what it's worth, here is a thread on a major Web discussion board that has
just added the ability to use a <font face = "symbol"> tag for its users:

http://boards.straightdope.com/sdmb/showthread.php?threadid=90639

Judging by the excited reactions there, I doubt anyone will be persuaded to
discontinue its use anytime soon.  Add my vote to the list of people who would
deeply appreciate it if this feature, "wrong" though it may be, was supported
somehow on Mozilla / Netscape.  Since I do not have control over every web page
on the Internet, the fact that there are more standards-compliant ways of
publishing Greek letters is meaningless to me as an end user.  The steady stream
of duplicates of this bug report ought to tell you something :-)
> The steady stream of duplicates of this bug report ought to tell you something
 > :-)

That the Teeming Millions are alive and well?  Somehow, I think the honorable
posters at the SDMB would be just as happy if they could use numeric character
references instead, and not only discuss math, but, say, put Arabic epigrams in
their sigs or use those cute miscellaneous symbols.

Oh, and FWIW, I checked out the thread on a stock install of Konqueror (latest
version) with the usual xfonts-* and xfonts-*-transcoded packages installed, and
saw broken characters and non-fontfaced characters.  So I'd say that, in
general, this technique doesn't work for users running Linux.
> I'm not sure why you claim Symbol has no character at position #97

I didn't claim that. I claimed that it had no character at _ISO-Latin-1_
position #97. That is not the same.
>On what other non-Windows browsers does this symbol font trick "work"?

Currently, it does not "work" in any Mac OS X browser, which is correct. This
bug should return to INVALID.
> Currently, it does not "work" in any Mac OS X browser

It's not what I see.  On my machine, IE 5.1 displays correctly pages such as:
  http://praiseofglory.com/torre.htm
  http://www.ornl.gov/fed/stelnews/sn78/sn78.html
Check your settings, maybe.
I reopened the bug mainly to reopen the debate and get the bottom line arguments 
on each side.  For now at least we all agree that if something is broken, it's 
the legacy, otherwise there hasn't been much of a convergence of opinions.  The 
problem is that with the wider adoption of Gecko as a rendering engine, we 
(Netscape) are pressured to become more compatible with the legacy.  Until now, 
attempts to fix the problem were denied with arguments such as "By forcing 
authors to do the right thing, Mozilla would be improving the web overall on the 
long term"... a position that was deemed "extremely ignorant".  I would like to 
call to everybody's goodwill and try and reach a consensus.  Here is an approach 
to the problem, and a possible solution.

Usability of symbol fonts in Mozilla:
-------------------------------------
With the current code, there isn't any way to display a symbol other than by 
addressing it by its unicode name or value, as in |&alpha;| or |&#945;|.  It is a 
limitation, for instance for pages that make use of funny dingbats and cater only 
to a limited set of platforms (let's not be blind: it happens all the time with 
browser-sniffing).  We also presume that all symbols can be addressed as unicode 
values but I'm not sure it is true (can someone comfirm?).  Another limitation is 
that to write truly cross-platform pages that are supported by all the main 
browsers, the symbols must be addressed by values only and not by name, thus 
making the development of new pages and the conversion of old ones a fairly 
arduous process.

Frequency of bug:
-----------------
We have 10 dups already (this bug will soon make it into the most frequent list) 
and several related bugs were opened within both databases - Bugzilla and that 
other one for you-know-who.  Bug reports were filed both by internal and external 
users.  We have frequent recurrences under different forms, with one font or 
another, within one module or another.

Attempts to address the problem:
--------------------------------
To fix one of the Netscape-internal bugs we even went to such an aberration as 
Bugzilla bug 94319: a Windows-only solution that was checked in on the 0.9.2 and 
0.9.4 branches but not on the trunk (see bug 94319 comment #32 and following).  
What are we going to do on Mac and Unix and other platforms?  What are we going 
to do on other branches?  Do we plan to checkin that patch over and over again on 
each branch and never on the trunk until someone implements a dingbat character 
picker dialog in the Mail Compose window?  But then what about the Editor?  What 
about customers that use 3rd-party editor?

Another contradiction:
----------------------
Symbol fonts (especially the "Symbol" font with greek alphabet) were defined a 
long time ago in part as an easy way to display funny glyphs, but in Mozilla the 
only way to access them is through cumbersome unicode values.  Now I can't 
imagine why an author would knowingly select a symbol font but still want the 
western alphabetical characters to be displayed into another font that covers the 
western alphabet.  It doesn't make sense to me.

Making it a quirk:
------------------
This bug matches the criteria to be implemented as a quirk:
- The most widely spread browsers (let's say 90%+ of the market) support the 
display of symbol fonts through the FONT tag, in current versions and previous 
ones too.
- There are a many pages that display dingbats and greek characters the easy way, 
through the FONT tag. A lot of these pages have been around for ages, don't seem 
to be maintained, are developed by people with rudimentary tools.  They can't all 
be evangelized.

A minimal-impact solution:
--------------------------
If we are in quirks mode
If the current font is a symbol font (see bug 77265 commnent #23)
If the characters are within the 0-255 range
If the document's character set is missing or is the default one (like 8859-1)
If the font doesn't contain the glyphs for these characters
Then use the characters as indexes within the current font
>> Currently, it does not "work" in any Mac OS X browser
>It's not what I see.

So not only does the symbol font work consistently across operating systems, 
but it also doesn't work consistently within at least one popular OS.
I really fully agree with the comments from Pierre! Two more comments:
1) If it makes some developers happy, pop up a window the first time
mozilla hits a page which uses the symbol font. In particular let the
user choose the behavior (s)he whats.
2) Feel free to remove the code once 90% of the browsers in use support
&alpha; and co.
> pop up a window the first time mozilla hits a page which uses the symbol font


                                      No.
> 2) Feel free to remove the code once 90% of the browsers in use support
> &alpha; and co.

they do.

> With the current code, there isn't any way to display a symbol other than by
> addressing it by its unicode name or value, as in |&alpha;| or |&#945;|. 

This is incorrect. You can also embed the character directly just like you can
embed "a" directly without using entity references.


Pierre: What do you do about encouraging authors to leave Quirks mode and write
pages that are more accessible cross-platform?
Note that back in August this was discussed for the 0.9.4ec branch. At the time
I got a committment from various people within Netscape that Netscape would no
longer push for this and would instead persue two alternatives that I had
proposed, the main one being to change the application that required this to
provide a dropdown of typical dingbats just like we have a drop down of smilies
in Mozilla, using UNICODE and not the Symbol font.

There are very important accessibility reasons not to do the wrong thing here.
We have already a well defined "workaround" for authors. Why is this bug not
being WONTFIXed or INVALIDated?
This religious argument is what is ideally right versus what is practical. As
long as Mozilla supports the correct things, it is not WRONG to support the
"quirks." 
Until the applications I use )FrameMaker, WebWorks, Word,...) get updated to let
me easily insert unicode for special characters, it is truly onerous to do it by
hand in exported html. Web publishers do not usually write their stuff directly
in HTML.

I do not even have a simple equivalent of the Windows character map application
that will allow me to easily find the unicode characters. Without Web
publishers, Mozilla will not have anything to display. Furthermore, I must often
abandon Mozilla to work with other publusher's pages. It is fine top say "they
are nonstandard and wrong," but the poor users do not really give a flip. They
just want to see all pages correctly on their browser. 
>> 2) Feel free to remove the code once 90% of the browsers in use support
>> &alpha; and co.
>they do.
I'm giving up. By pretending you know everything better and killing every
constructive approach right from the outset, you render this discussion
into a big waste of time (at least for me)!
James:
> This religious argument is what is ideally right versus what is practical. As
> long as Mozilla supports the correct things, it is not WRONG to support the
> "quirks." 

Define "wrong". If "wrong" means "does not comply with the specs" then it is
"wrong". If "wrong" means "continues to encourage authors to do the wrong thing"
then it is "wrong".


> Until the applications I use (FrameMaker, WebWorks, Word,...) get updated to 
> let me easily insert unicode for special characters, it is truly onerous to do 
> it by hand in exported html.

Speak to your application provider.


> I do not even have a simple equivalent of the Windows character map 
> application that will allow me to easily find the unicode characters.

   http://www.unicode.org/charts/


> Without Web publishers, Mozilla will not have anything to display.

Thankfully, this issue is not as big a deal as most of our quirks. (Few pages
break noticably if a diamond dingbat turns into an F or whatever.)


Gerald:
>>> 2) Feel free to remove the code once 90% of the browsers in use support
>>> &alpha; and co.
>> they do.
> I'm giving up.

What part of my statement are you challenging? That IE doesn't support &alpha;
and co? Or that IE doesn't have 90% of the market?


> By pretending you know everything better

This isn't a matter of "knowing" anything, I don't think we disagree on any of
the facts do we? We all agree that using the Symbol font is technically wrong,
we all agree that UNICODE is the way to go, and so on. The specs don't leave
much room to disagree on these issues.

The only thing I see us disagreeing on is whether to continue support legacy
behaviour. This isn't a matter of knowing anything, it's a matter of policy and
belief; a question of whether we should support badly authored pages.


> and killing every constructive approach right from the outset,

You mean by disagreeing with you?
Some discussion of authoring methods which are standards-compliant but work in
NS 4.x is a <http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.html>,
particularly Scenario 6.  I recommend this as a comprehensive reference to
practical and theoretical charset issues.  To summarize, setting the charset to
UTF-8 though HTTP headers or <meta http-equiv="Content-Type"
content="text/html;charset=utf-8"> will cause NS 4.x to interpret these entities
correctly, as more up-to-date browsers already do.

I'm afraid I'm at something of a loss to suggest authoring solutions on the
Macintosh; Word 98 and up apparently support Unicode, and inserting an 8-bit
Unicode character directly into the document should also work (provided that the
document is properly advertised as UTF-8, see above), but the platform support
for multilanguge characters on pre-OS X Macs seems to be a rather confusing
blend of proprietary character encodings and mappings, such that I'm uncertain
what would happen to Unicode characters during the Word-to-HTML conversion
process.  Assuming here that the FrameMaker output is being run through WebWorks
Publisher before being put on the web, it seems that the solution is to add an
entry to WebWorks' character mapping table converting the internal FrameMaker
representation to the Unicode numeric entity.  Unfortunately, I'm not familiar
with how FrameMaker does these things (aside from the fact that it doesn't
handle Unicode, despite pretensions to XML support); mail to wwp-users at Yahoo
Groups would probably be the best shot at figuring out how this works.
I did this 
(To summarize, setting the charset to
UTF-8 though HTTP headers or <meta http-equiv="Content-Type"
content="text/html;charset=utf-8"> will cause NS 4.x to interpret these entities
correctly, as more up-to-date browsers already do.)

and still no joy for codes like &alpha;

It is not Mozilla's mission to change the world IMHO. 
Could you show us the page you were having trouble with?
That stellarator news page has both those headers and Netscape still does it wrong.
WebWorks lets you choose utf8 and it puts the header in. But it is unable to
change the symbol font references in FrameMaker, so I must do it by hand which
is terribly tedious.
> That stellarator news page has both those headers and Netscape still does it 
> wrong.

Could you give us a URI?

> But it is unable to change the symbol font references in FrameMaker, so I must 
> do it by hand which is terribly tedious.

I understand. Could you give me an example of a page created by FrameMaker so
that I can write you a script to automatically convert them to a format
compatible with both Nav 4.x and standards-compliant browsers?
Ian, go to google, type in this: face="symbol" -- you should get over 5,000 
hits, just take a look at the first page and you should have several pages that 
you could use as a real world test
Ian made an excellent summary when writing "The only thing I see us disagreeing 
on is whether to continue support legacy behaviour".  To those who are not 
familiar with the development process on Mozilla, it is a question we face almost 
on a daily basis.  Disagreements can be fierce but we usually reach a consensus 
and if we don't have one, we vote or escalate the issue.

> Pierre: What do you do about encouraging authors to leave Quirks mode and write
> pages that are more accessible cross-platform?

There are several ways to educate people and increase public awareness.  Breaking 
pages should be used as a last resort.  I can understand it for instance if a 
quirk precludes authors from adopting of a new standard.  In other cases, if the 
patch is technically difficult or has too many drawbacks, and if the number of 
pages that would benefit from it is fairly limited, we can decide to not 
implement it and evangelize the webmasters instead.  But the latter requires a 
lot of effort in communication: we cannot repeat very often what we did for the 
LAYER tag.

The quirk I proposed falls into neither category: it does not block progress and 
it seems to me technically sound.
- Authors can, if they have the knowledge and the tools, follow the standards and 
know that their new pages will be supported by 90% of the market.  The quirk does 
not prevent them from doing so.  You listed some very good points regarding the 
benefits of adopting unicode, including some that I had not thought of, but the 
fact is: breaking the pages in that particular case won't do much to get the word 
out and further the cause.  Interestingly enough, I did the same test as beppe 2 
days ago: there are still lots of pages using <font face=symbol>.  Many of these 
are written by people whose main jobs are not web publishing but things like 
history, physics or chemistry.  I also saw personal pages with hearts or clovers 
(not to mention the infamous "NYC" and "Q33" displayed in Wingdings-36), and we 
could probably find enterprise web applications that require particular symbol 
fonts (for instance in process control or terminal-emulation).  If Mozilla breaks 
these pages, the most expert of the authors will log onto bugzilla and file bugs.  
The other ones will think that their pages are fine because they display 
everywhere else, so Mozilla must broken, and they'll move on.  We cannot 
evangelize them all the way we did for CNN or WellsFargo.  At the most, we can 
evangelize the authors of HTML tutorials and the developers of authoring tools, 
but not the public at large.
- Technically, the proposed quirk would be much more innocuous than Nav4 for the 
simple reason that it would only apply to symbol fonts.  Script fonts are not 
affected.  If you connect to a japanese site but don't have the fonts on your 
machine, you continue to see the question marks (like in Moz and IE) and not some 
weird accentuated characters (like in Nav4).  Similarly, if you install a 
japanese font and write a page that selects it and displays "abc", Mozilla 
continues to show "abc" and not some japanese characters.

The other reasons for me to reopen the bug and consider a quirk are:
- Dups are piling up, and they continued to do so since last August.
- Compatibility with the legacy and the competition is higher in the list.
- The current solution, that was checked into two Windows branches only and for a 
very limited set of symbol fonts, is a shame (yes, really :-), much worse than a 
good quirk.

Now the question is (and that's where I'll need all your scrutiny): is the quirk 
as innocuous as I claim?  If we don't all agree that it is a smaller harm than 
breaking the pages or maintaining the patch for bug 94319, we'll ask higher 
authorities to share some words of wisdom.
I am curious as to why Netscape contributors are pushing for this given the
assurance I was given by valeski, marek, and ftang in the previously mentioned
meeting (which came out of bug 94319) that AOL and Netscape would not be pushing
for this change in the trunk.

This affects many pages, but most users do not even notice the difference unless
it is pointed out to them (especially things like the abuse of the "clubs"
symbol or other decorations). Yes, a minority of pages are unfortunately badly
affected by this (the scientific papers) but first of all those pages are
already broken on many platforms (and academics are the first to start using
"alternative" platforms, so this definitely already affects them) and second
these pages are written by easily evangelised authors (academics are, on the
whole, technophiles, and eager to learn things like this).

We have many serious bugs that affect more pages than this _and_ are standard
compliance issues. I am working on writing tools to help authors who have pages
like this make the transition. Could we please focus our bug-fixing efforts
somewhere more worthy of our time?
> This is just like saying "We don't give a damn about scientists"

Probably the majority of people who comment actively in Bugzilla have studied
mathematics, physics or computer science. Everyone here knows that people want
to represent alpha in documents. However, <font face="Symbol">a</font> is not
the solution. It is part of the problem.

>> Currently, it does not "work" in any Mac OS X browser
>It's not what I see.  On my machine, IE 5.1 displays correctly pages >such as:
...
>Check your settings, maybe.

Apparently, the test case I used didn't represent the situation fully. I tested
initially with <font face="Symbol">Ö</font>, where Ö is Ö encoded as ISO-8859-1
or CP1252.

It turns out that Mac IE 5.1.3 displays <font face="Symbol">a</font> as alpha in
any case. However, a higher code point such as <font face="Symbol">Ö</font>
displays as a square root only it the quirks mode of Mac IE 5.1.3.

Anyway, <font face="Symbol"> still doesn't make Opera or OmniWeb treat the
character byte as a glyph index for the Symbol font. Also, the correct Unicode
method works in IE.

>2) Feel free to remove the code once 90% of the browsers in use 
>support &alpha; and co.

We all know that it is really hard to undo quirks. Let's not put more of them in
in the first place.

>1) Every other program on my Mac, whether it's a browser, word
>processor, or graphics application, recognizes this font as any 
>other. The character at ISO-Latin-1 position #97 happens to look 
>like a lowercase Greek alpha in this font.

Then you are using an old-world app that has no knowledge of Unicode. If I type
the Latin small letter 'a' in TextEdit (the successor of SimpleText on Mac OS
X), select the letter and change the font to Symbol, the character still looks
like the Latin small letter 'a', because I entered a character whose essence is
"Latin small letter a"--the meaning is not "glyph number 0x61 in whatever font".

>2) The design of any character, at any position, should be up to 
>the font designer, not the browser. The character at #97 is usually 
>something recognizable to the eye of an English-savvy human viewer 
>as some form of a lowercase English "a". It could look like an alpha, 
>Pisces, or a maple leaf if that's what the font designer has in mind.

Unicode (and therefore HTML) doesn't encode font glyph indeces. It encodes
characters. I recommend reading some good documentation on the differences
between Unicode numbers, byte representations in character encodings and glyph
indeces.

>The quirk I proposed falls into neither category: it does not block 
>progress and it seems to me technically sound.

The problem is that, in a way, implementing a quirk like this at this stage is
an endorsement of the quirk. It signals to authors: "Go ahead, go on using bogus
authoring practices." Then the authors can not only say: "But it works in IE!"
they can also say "It works in Mozilla, so it must be right since Mozilla is
standards-compliant." Then broken content would stay out there and
browser-makers with less market share would be pressured to implement the quirk,
too. That's how misfeatures spread. For example, browsers that use Apple's
Unicode implementation (eg. OmniWeb) don't display an alpha for <font
face="Symbol">a</font> but do display alpha for &#945;. Anyone implementing a
browser would have to special-case Symbol in order to support this bogosity and
couldn't just go with the system API.

>The other ones will think that their pages are fine because they
>display everywhere else, so Mozilla must broken, and they'll move on.

But they *don't* display everywhere else. Making them display in Mozilla would
spread the bogosity.

Couldn't time and effort be directed at fixing real bugs instead of copying IE's
bugs? This one really should be INVALID.
From a previous posting of mine:
>1) Every other program on my Mac, whether it's a browser, word
>processor, or graphics application, recognizes this font as any 
>other. The character at ISO-Latin-1 position #97 happens to look 
>like a lowercase Greek alpha in this font.

henris@clinet.fi had responded:
>Then you are using an old-world app that has no knowledge of Unicode.

OK. But I'm not using AN old-world app, it's ALL the app's I have ever used,
including utilities for looking at the character sets within fonts (Key Caps,
Font Explorer, and PopChar, e.g.). I fully accept the possibility, and even
probability, that none of them have knowledge of Unicode; however, the
oft-repeated indication from the "people-in-the-know" has been that the Symbol
font is somehow unique/different/non-standard.

Ian (Hixie) told me/us, "... the Symbol font, internally, claims to NOT have any
character at ISO-Latin-1 position #97."

Really? What's there? ALL these apps act as though there IS something there -- a
glyph that looks like an "alpha". The font utilities specifically identify it as
such. And where is the "alpha" glyph?
Am I supposed to believe that EVERY program I have ever used has a hack built
into it to deal wth this one screwball font? That's ludicrous!


henris@clinet.fi continued:
>... type the Latin small letter 'a' in TextEdit
>... and change the font to Symbol, the character still looks like the
>Latin small letter 'a', because I entered a character whose essence is "Latin
>small letter a"--the meaning is not "glyph number 0x61 in whatever font".

OK. I accept that Unicode is a standard and it now applies elsewhere, not just
Mozilla and "the Web", although I don't fully understand the logic behind such a
system.
Now I'm curious: What happens if you choose a font like "Wingdings" or
"Dingbats", or something like that? I bet you get the funny glyphs specified by
those fonts, because that's what I still get with Mozilla.

I had previously argued/suggested:
>2) The design of any character, at any position, should be up to 
>the font designer, not the browser. The character at #97 is usually 
>something recognizable to the eye of an English-savvy human viewer 
>as some form of a lowercase English "a". It could look like an alpha, 
>Pisces, or a maple leaf if that's what the font designer has in mind.

henris@clinet answered:
>Unicode (and therefore HTML) doesn't encode font glyph indeces. It encodes
>characters. I recommend reading some good documentation on the differences
>between Unicode numbers, byte representations in character encodings and glyph
>indeces.

Thank you. I mean that seriously. I looked at some stuff at the unicode.org
website for information, I think I understand this issue a little better now.

Now maybe someone can answer this, because I believe I've got a way to solve the
entire problem, even with my minimal knowledge.
Referring back to the above TextEdit experiment, and the fact that even Mozilla
displays wingdings glyphs as the font intends, all that we
backwards-thinking/non-compliant people want is a font that does indeed have
characters at the Unicode positions for the Latin alphabet whose glyphs are
rendered to look like Greek letters.
The standards-minded people would be happy, or at least incapable of undoing this.
The non-compliant people would still be able to type an "a", change the font,
and get something looking like a Greek "alpha". This would/should then be true
across all the applications we might use, right?
The only unhappy people would be those in Greece trying to look at my
biochemistry class' website, who would see my "alpha-ketoglutarate" as
"a-ketoglutarate". I don't care about them; they never come to class anyway.

So, if there are any font designers out there, how about it? Would this work?

One last thing, NONE, and I repeat NONE, of the supposedly "correct" methods for
having an "alpha" appear on my screen in Mozilla works. Please see BUG ID#110373

Michael
I'll escalate the issue. The bug was fixed on the 0.9.2 and 0.9.4 branches for 
Windows and only for 2 fonts specified in 'fontEncoding.properties' (see http://
lxr.mozilla.org/seamonkey/source/gfx/src/windows/fontEncoding.properties#85).

What about other platforms? What about other symbol fonts? What about future 
branches? I can't believe Marek and Judson signed on a fix like that in all 
conscience. The presentation they had of the problem and the proposed solution 
must have been quite biased. I'll submit my views in the coming days and copy the 
other persons who were involved in the decision process (bug 94319).
Keywords: mozilla1.0
Note. The Webdings and Wingdings font only work because a similar hack was put
in place for those fonts. IMHO those hacks should be removed.

Pierre: I repeat my previous point, to which I notice you did not respond:

This affects many pages, but most users do not even notice the difference unless
it is pointed out to them (especially things like the abuse of the "clubs"
symbol or other decorations). Yes, a minority of pages are unfortunately badly
affected by this (the scientific papers) but first of all those pages are
already broken on many platforms (and academics are the first to start using
"alternative" platforms, so this definitely already affects them) and second
these pages are written by easily evangelised authors (academics are, on the
whole, technophiles, and eager to learn things like this).

We have many serious bugs that affect more pages than this _and_ are standard
compliance issues. I am working on writing tools to help authors who have pages
like this make the transition. Could we please focus our bug-fixing efforts
somewhere more worthy of our time?
Ian: I did not ignore your objections, I wanted to include them in a summary of 
the problem that I will send to the Netscape and Mozilla folks (you included) who 
have an interest in text rendering.  The bug allowed to collect many opinions but 
the differences of appreciation of the different parties (and the fact that none 
of us is invested with fascistic powers) make it almost impossible to reach a 
decision here.

The number of duplicate bugs and the obligation of moving the 0.9.2/0.9.4 fix 
from milestone to milestone makes it worthy of our time to find a long term 
solution. The fix for bug 94319 is a shame. If the presentation of the problem 
you made last August had been fair, we could have reached a more sensible 
solution back then.
Bug 94319 was filed because it made *mail* messages written by people expecting
the symbol font behaviour to come out without the expected happy face symbols,
etc, which the Symbol font contains.

At the time I outlined a very simple fix for this bug which would also improve
the UI: Change the relevant mail applications to have a drop down with lots of
characters like those in the Symbol font, but which when inserted insert the
relevant UNICODE code point, instead of using the Symbol font.

Members of that discussion agreed that this was not an issue as far as the web
goes, because as I have repeatedly said on this page it only _noticeably_
affects a minority of site whose site owners are in the more technophile,
demographic anyway, and whose visitors will *already* be having problems viewing
the symbols since many of them will be using exotic platforms that do not have
the Symbol font in the first place (e.g. Linux).
*** Bug 114737 has been marked as a duplicate of this bug. ***
In comment 90, Ian says:

"This affects many pages, but most users do not even notice the difference unless
it is pointed out to them (especially things like the abuse of the "clubs"
symbol or other decorations). "

This is not true at all in languages like Japanese, Chinese and Korean where
the symbols like infinity mark, club, heart, diamond, and spade are
used in a number of pages I encountered. Characters appearing instead
of these charaters are in the rarely used Japanese code range that
users notice something is wrong immediately. 

The Japanese character which appears in instead of the heart, for example, is
totally incongruous in such context and rarely used that users will **notice
immediately** that "browser is broken". See for yourself:

http://www.chaldea.ne.jp/atelier/b/me_link.htm

I don't mind evangelising against such sites but we should **NOT
look broken ** compared to other browsers in the meantime. 
momoi: could you be more explicit? I don't understand Japanese! :-) What glyph
do we render for the character which people (incorrectly) use to trigger a heart
when using the Symbol font?

Certainly it is unfortunate that the problems are more noticable in other languages.
Ian, the page I pointed to is a left frame of a page that has the righ side but 
for this purppose, I omitted the other frame. You see on the page what amounts
to "bullets" -- 6 of them -- as the first character of each major items. They are 
supposed to be "hearts". If you try IE or NN4, you'll see the difference
immediately. 
The symbol they turn into, though -- what does it represent? I can't read
japanese, and to me it just looks like a funky bullet type.
> The symbol they turn into, though -- what does it represent? I can't read
> japanese, and to me it just looks like a funky bullet type.

Ian, that symbols is half-width Katakana character pronounced as short
vowel "u". This is a character which makes no sense in the context that 
it appears and so that the user knows immediately that something is 
wrong.

That's no worse than what happens on Latin1 pages, which is IMHO not a big deal.
> That's no worse than what happens on Latin1 pages, which is IMHO 
> not a big deal.

It's a matter of opinion and I disagree with yours. The current behvaior
sucks and we appear broken compared to other browsers. 
Our current behaviour may not give the user the best impression, but it at least
encourages authors to fix their broken pages.

In any case, like I said above, we have many much more important bugs to worry
about that affect existing web pages in much more serious ways than this one.
> In any case, like I said above, we have many much more important bugs 
> to worry about that affect existing web pages in much more serious 
> ways than this one.

Speak for yourself. That is your assessment and I cannot agree with you
on that. No amount of you telling me platitudes is going to change the
fact that we appear broken on a number of pages . Besides, dealing with 
this problem is not that hard codewise. We watse more time arguing about 
it than actually fixing it.

This is also not entirely a Mozilla bug.  As others and myself have pointed out, this "trick" already produces inconsistent results in other browsers on both Linux and OS X.  This is not a "Mozilla is broken" issue; it is a "webpages are broken" issue, and our current behavior makes authors aware of that fact.Obviously, I can't stop this from going in.  But undoing an important correctness issue for which we've explicitly been praised by an expert in the field sends a message, like all our decisions, and I'm increasingly unhappy with what the message is.
> We watse more time arguing about it than actually fixing it.

By saying that, you're asserting that your side of the argument is right.  The
other side says that we're better off not fixing it.
> That is your assessment and I cannot agree with you on that. No amount of you 
> telling me platitudes is going to change the fact that we appear broken on a 
> number of pages.

Those pages appear broken *anyway* on non-Windows platforms.


> Besides, dealing with this problem is not that hard codewise.

Dealing with this problem is *impossible* code-wise. The problem is that authors
are using the wrong code points. Papering over this issue is a losing battle --
we would have to keep adding fonts to our list, ever decreasing the 
the encouragement for authors to make their pages more accessible.


> We waste more time arguing about it than actually fixing it.

The time "wasted" arguing about this bug is nothing compared to the amount of
time and effort that will be wasted by people if we do what you propose.
You correctness bigots get in the way of usefulness. I point out that PDF, for
example, has the symbol set embedded in it by default, and any other required
font can also be embedded in the file. So, as a better solution, I would suggest
having the ability to embed fonts in an html file.

It is still impossible to use unicode in most major publishing packages. Adobe
has announced that unicode support is a major effort and it will NOT be in the
next version of FrameMaker either. 

James: I'm not entirely sure what "embedding the font" in an HTML file is supposed to mean; the format of HTML ("logical" markup) is significantly different from PDF/Postscript that I don't think this would be possible.  The CSS2 font spec might come closer, but implementing that is a tremendous challenge.To speak to your problems with FrameMaker, http://www.scriptorium.com/tc2001.pdf suggests that by adding character entities to the "character mapping list" in "Style Designer" allows you to output Unicode entities.  I'm not familiar with the workings of the FrameMaker->WebWorks publishing system, but this seems like the right area.  (In a curious bit of irony, it seems that the published Unicode Standard was typeset in FrameMaker.)
Unfortunately the WebWorks mapping you recommend is only available in the
standard WebWorks Publisher, which is not included with FramerMaker. The Regular
version costs several thousand dollars. More than FrameMaker cost!

This points out the problems people have to try and comply with a standard that
is not yet practical. Compliance is good. Accepting other kludges to allow
people to get their jobs done is also good.
If people care more about looks than structure then they *should* be using PDF.
*** Bug 121358 has been marked as a duplicate of this bug. ***
Moving to mozilla1.1. Engineers are overloaded!
Target Milestone: mozilla1.0 → mozilla1.1
Following a discussion with the authorities, it was decided that the previous 
behavior (ie. support for symbol fonts through the FONT tag) should be 
implemented as a quirk.
Whiteboard: INVALID/WONTFIX
Target Milestone: mozilla1.1 → mozilla1.0
To be more specific, you proposed that this be:
 * quirks mode only
 * limited to a small subset of fonts ("Symbol" and maybe a few others)
Quirks mode only, yes, but it should apply to all the symbol fonts - not just a 
limited set of fonts unless the 'symbol font' bit is not available on a 
particular platform (rbs knows how to get that bit: see bug 77265 comment #23).
Any chance we could really limit this to the <font> tag? (i.e. CSS wouldn't be
affected?) That would actually still be standards-compliant, would be a good way
of weening people off Symbol, and would satisfy the Symbol-in-mail requirement.
It would also mean we wouldn't have to implement it as a quirk. I imagine it
would be relatively easy to implement (internally turm the Symbol font into
-moz-Symbol if it is sot on the <font> element, and go from there).
ian, why do you insitst on making life harder for most of the world. Complying
with a standard is fine, but adding needed extensions is also OK. It is not the
role of Mozilla to change the way the world does its business.
Stop trying to minimize the fact that we're willing to break with the standards
in order to help compatibility by claiming that being noncompliant is an
"extension".
Ian's suggestion makes sense.  Quirks are designed to support incorrect behaviors 
when the number of faulty pages is too large to evangelize but they don't need to 
fully emulate the legacy browsers: their scope can be limited depending on what 
we find in actual pages.  AFAIK, all the bugs were reported against the use of a 
symbol font inside a FONT tag.  I'm not aware of any faulty page using style 
declarations such as:
    SPAN.greek  { font-family: "Symbol" }
    P.icons     { font-family: "Wingdings" }

I guess the decision regarding the scope of the quirk will come from 
implementation constraints.  If the quirk fits in XP code (Text Layout), we can 
restrict it to the FONT tag.  If it must be done in platform-dependant GFX 
modules, it will be broader.  We also need to look into how the Editor handles 
fonts now and how it will in the future.  If the FONT tag is deprecated and 
replaced with STYLE attributes, as I think it is (or will be), we'll have to go 
with the broader scope too.
I would like to point out that I have attempted using CSS to avoid this
"problem", since this does work in other browsers. Even as someone who considers
this evangelism to be inherently wrong, I can agree with the concept of a quirks
mode that does not include allowance for using the Symbol font in CSS.
However, currently Mozilla DOES support the use of "Wingdings" both within the
FONT tag, AND as a style declaration in CSS.
The problem still exists that the supposedly proper (i.e., standards-compliant)
methods for displaying "symbol characters" do not work. Please see bug report
#110373 and an example page at
<http://www.bmb.psu.edu/courses/psu16/sypes/fonttest.html>

Thank you.
Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1
Comment on attachment 56718 [details]
HTML for page of screenshot showing Netscape 4.78 does indeed support Unicode mathematical operators on Windows

4.79/Win95 only shows me the top symbol, the other two just appear as boxes.
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.
Priority: P3 → P1
Target Milestone: mozilla1.1 → Future
Changing QA contact
QA Contact: chrisd → madhur
Whiteboard: either WONTFIX or see comment 119
For what it's worth, one can obtain the non-standards-compliant behavior
(treating <font face = "symbol">a</font> as an index to glyph # 97 in the
symbol font) by aliasing a symbol font to claim that it is iso8859-1.
Scripts for this workaround are available here:

http://hutchinson.belmont.ma.us/tth/Xfonts.html (Unix)
http://hutchinson.belmont.ma.us/tth/Wfonts.html (Windows)

and I've verified that it works at least on Linux (Debian unstable).

I mention this for two reasons.  First, it seems to me like an acceptable
compromise not to implement a Symbol font quirk, but merely refer to the
above web pages in a Mozilla FAQ or something.  Second, since many people
who commented on this bug (like me) probably want such a workaround, this is
a good way to let them know about it.

(Before anyone asks, I have no personal or business relations with the
creator of those web pages.)
Blocks: 145052
cc'ing myself
I have been searching for the standard that displaying the Symbol font violates
and have not been able to locate it.  The page at
http://www.hclrss.demon.co.uk/demos/symbol.html says that using the Symbol font
to display Greek "is deprecated in the HTML 4.0 Specification."  I have searched
for this but not been able to locate where the HTML 4.0 Specification says this.
 However, if it is true, displaying the Symbol font is merely deprecated and not
excluded.

I will not dispute that character #97 is not defined for Latin-1 in the Symbol
font.  The question then must be, "Why does Mozilla currently display character
#97 as a Latin 'a' in the Symbol font?"  This seems to be a contradiction.  If
it is not defined for Latin-1, then it should not be displayed as a Latin
character.  Further, the question must be asked as to why it should be displayed
as a Latin-1 character.  The HTML 4.0 Specification clearly says at
http://www.w3.org/TR/REC-html40/charset.html, "user agents must <b>not</b>
assume any default value for the 'charset' parameter" (emphasis mine).  This is
in the paragraph that speaks of ISO-8859-1 (Latin-1) as a potential default
character encoding.  It is a violation of the HTML 4.0 Specification for Mozilla
to assume that all font faces must have Latin-1 character encoding.

The claim that Linux does not have a Symbol font so Unicode must be used to
display Greek does not have much merit.  I went to our school's Linux server and
launched the version of Netscape 4 that came with it.  I could see neither the
Symbol font nor the Unicode for Greek.  Linux is a great server, but still lacks
something as a workstation.  Someone needs to create an Open Standards Symbol
font for Linux.

My own interest in having Mozilla display the Symbol font comes from my interest
in Biblical studies.  There are a number of competing ASCII Greek fonts. 
However, to use them on Web pages, they must be downloaded and installed on the
user's machine.  Since the Symbol font has the same mapping for Greek letters on
both the PC and the Mac and comes installed on both, it is useful to write Greek
in the Symbol font so it can be seen by most users.  It is displayed on every
major browser on the PC and Mac except for Mozilla.  And as a recent posting
notes, it is not hard to change Mozilla so it can display the Symbol font, too,
although it is aggrevating to have to change it to use it.  

For those who would claim that Unicode is better than ASCII Greek fonts, the
problem is that one cannot type in Greek in Unicode.  I can type in Greek on my
keyboard in Symbol font and several of the Greek fonts.  The escape codes such
as &alpha; are hard to write, only work in the newest browsers, and take up
bandwidth when used for large sections of text.  I am not aware of a text editor
that lets one type in Greek in Unicode.  I even tried it in the Mozilla
composer, but that didn't work either!  If Mozilla is going to insist on Unicode
for the display of Greek, its editor should allow one to type Greek in Unicode.

Personally, I have a problem with the idea that one must use Unicode on pages to
display non-Roman alphabets, the idea that Roman alphabets can get by with ASCII
8-bit text, but other alphabets must use 16-bit text.  In the field of
anthropology, I think that is called ethnocentrism.  Why should other alphabets
not be allowed to have 8-bit encoding?

As a test, I tried five Greek fonts in addition to Symbol.  Two of them work in
Mozilla.  One of these has the same character mapping as Symbol for Greek. 
Perhaps that is the solution, especially since it is a free font, is the same on
the PC and Mac, and has the diacritical markings that Symbol lacks. 
Interestingly, IE and Opera displayed all of the Greek fonts, including Symbol.
 However, Mozilla's lack of support for the other 3 Greek fonts means that users
cannot use it with the Perseus website at Tufts University where most of the
classical Greek writings of the ancient world are on-line.

But then, when all is said and done, the fact still remains that Mozilla is not
displaying the Symbol font face, which is what the authors of the web pages
which use the Symbol font intended.  It is rendering the page, not as the author
wanted it to be viewed, but in a way that obscures the page in the hopes that
the author will recode the page.  An interpretation of the standards is made
more important than information that people have tried to share.  When one
speaks of what is 'wrong,' that is what is 'wrong.'
It's well beyond deprecated.  It's incorrect.  What says so is chapter 5 of the
HTML specification, http://www.w3.org/TR/html4/charset.html .

Note in particular that 5.1 says:  "SGML requires that each application
(including HTML) specify its document character set." ... "HTML uses the much
more complete character set called the Universal Character Set (UCS)".

5.2 describes how the character encoding is a map from "a sequence of bytes to a
sequence of characters" in the document character set.  

Note also the definition of character:  "The section on the document character
set addresses the issue of what abstract characters may be part of an HTML
document. Characters include the Latin letter "A", the Cyrillic letter "I", the
Chinese character meaning "water", etc."
Bruce: You, the people who need several charset to coexist are the target of
this unicode support. You should realize that what you are asking for is a dirty
hack. Suppose you have some text which have some sections in hebrew, how it was
translated to greek and then the king james version... with unicode you can just
cut and paste that and use it anywhere. You can paste it in Word (if/when it
supports unicode) you can mail it to somebody. This is where computing is going,
and to achieve that, HTML was *specifically* designed to treat its content as
*unicode letters*, not bytes. Search in google for unicode editors, I've found
this one: http://www.unipad.org/main/ . It looks nice.
I feel compelled to weigh in again with Bruce, who wrote:
...  The escape codes such
as &alpha; are hard to write, only work in the newest browsers...
  If Mozilla is going to insist on Unicode
for the display of Greek, its editor should allow one to type Greek in Unicode.

Not only that, if Mozilla is going to insist on Unicode for the display of
Greek, its browser should display it properly when it is coded according to that
standard. As of build 2002051208, it still does not, at least not with MacOS
8.6. (See Bug ID #110373 if you're interested.)
*** Bug 145052 has been marked as a duplicate of this bug. ***
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: REOPENED → NEW
Priority: P1 → P3
*** Bug 159595 has been marked as a duplicate of this bug. ***
Obs to comment #122:

Look at the page mentioned in bug #159595 (marked as duplicate to this one) for 
an example using styles.
*** Bug 163300 has been marked as a duplicate of this bug. ***
removing bug 145052 from "bugs this bug blocks" because it has been marked as a
duplicate of this one



Why isn't this marked invalid? Even the summary says that this is no bug.
No longer blocks: 145052
ok, marking as such
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → INVALID
Being right does not always mean its the best way to go. There are so many pages
out there that break if symbol is nbot supported. Supporting this does NOT break
anything else, so why make users suffer for the sake of a blind adherance to
"standards."

As Grace Hopper used to say, "the nice thing about standards is that there are
so many of them."
*** Bug 166090 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
*** Bug 166843 has been marked as a duplicate of this bug. ***
*** Bug 94319 has been marked as a duplicate of this bug. ***
CSS fonts issue; taking QA.
Alias: symbol
Severity: major → normal
QA Contact: madhur → ian
Whiteboard: either WONTFIX or see comment 119 → either INVALID or see comment 119
Target Milestone: Future → ---
*** Bug 172280 has been marked as a duplicate of this bug. ***
What if we used XBL to convert the codepoints to the correct Unicode
equivalents? It probably wouldn't be the most performant solution, but it would
have two big wins: the rendering wouldn't be dependent on the Symbol font being
present on the user's system, and it would mean that I could copy and paste a
Greek quotation or mathematical formula into a Unicode compliant application
(such as Mozilla composer), and save it in a correctly encoded form.
I'm the one who originally reported the defect.  The URL is:
http://www.rsasecurity.com/rsalabs/faq/A-2.html
and the problem is that the math symbols are not rendered
correctly.

After so long I again visited the URL, but this time my IE
is updated to version 6 SP1 and ... guess what?  the IE now
renders the page exactly the same as Mozilla does!

Though I'm a layman on browser tech, from that I'm convinced
that it's not mozilla's fault: if both Mozilla and IE 6 agree
on a "bad rendering", the fault must be on the page itself!

I've just sent a mail to the URL's webmaster.  No reply got
yet.

*** Bug 177238 has been marked as a duplicate of this bug. ***
Alias: symbol
*** Bug 185736 has been marked as a duplicate of this bug. ***
*** Bug 193596 has been marked as a duplicate of this bug. ***
Note that our behavior on Windows was changed on bug 94319 -- supposedly we
treat symbol the incorrect, backwards-compatible, way when we're (a) in quirks
mode and (b) the 'Symbol' is specified in a FONT element rather than CSS (see
bug 175372 for those details).

However, the behavior isn't yet consistent between platforms and some bug
reports  (e.g., bug 193596) suggest that we may not even be doing what I thought
we're doing on Windows.
If I understand correctly, the decision made in bug 94319 was to implement every
symbol font *except* "Symbol", in order not to regress standards compliant
usage. The last few comments in the bug are not totally clear, but I think
that's what they are saying.
wouldn't it make sense, though, to allow it for plain byte characters, and, if i
dare be so bold, perhaps also for numerically specified entities from 128-255 only.

i'm not sure what standards-compliant usage this would regress... are there
ascii/latin-1 characters in symbol that i wasn't aware of? any that people have
actually used as such?

the INVALID keyword on this is extremely arrogant... if this is invalid, quirks
mode as a whole is invalid and should be scrapped.
See http://bugzilla.mozilla.org/show_bug.cgi?id=94319#c90 for more on the
compliant usage and why it is important.
how compliant can a usage that uses <font face> and triggers quirks mode be?

and, unless i'm reading something wrong, the fix proposed only applies when
&alpha; and the like are NOT present, so the only compliant usage it would break
would be compliant usage of latin-1 characters. does any compliant usage of
latin-1 characters within a <font face> tag specifying symbol as the font in a
page that triggers quirks mode in fact EXIST?
> unless i'm reading something wrong, the fix proposed only applies when
> &alpha; and the like are NOT present

You're reading something wrong.
regardless, couldn't a fix be made that _did_ only work in that case? or even
only on "raw" data (i.e. not entities) and only in 8bit mode?
"maybe".  It's a question of how much code that would involve and how much
rewriting of the font subsystem to accomodate this issue people are willing to
do, of course.  Given the will to write lots of code and make lots of changes,
we could support just about any sort of weird setup.
Barring that, just fix MathML. Symbol on windows isn't the same glyphs as Symbol
on mac/linux (on windows, it's a sampling of Times New Roman and MT Extra, on
Mac it's the original adobe glyphs, and i believe it's strictly bitmaps on
linux, though that depends on your setup)

make it use graphics for the stretches if you have to.
There's nothing platform-specific about the name "symbol".  It does not
matter whether the font is bitmaps or scaled as long as it provides the right chars.
Your comment seems to imply that support for <font face="symbol">
is more important than proper MathML rendering.  That is not the case
simply because <font face="symbol"> is the past, while MathML is the
future; given the choice between the two, MathML is the one to support.
the problem is that the issues quoted as the reason symbol is needed for mathml
depend on symbol having platform-independent glyph metrics. and that's bad
design in any case.
*** Bug 210529 has been marked as a duplicate of this bug. ***
*** Bug 209672 has been marked as a duplicate of this bug. ***
A greek TT font named "Athenian" doesn't work either (Mozilla 1.5, Windows
2000). (BTW, Symbol and Athenian seem to be not the only ones which don't
function). The problem is that at the moment, this is the only freely
distributed font one can use in a reasonable way for embedding chunks of greek
(with accents) within latin (german) context. There is a Unicode version, but it
can't be used on some applications.
So, if we don't want to encourage users to stick to IE, something has to be done
about this bug.
re comment #166
It's strange that Athenian doesn't work if it's similar to Webding, Ms Outlook
Express, Map Symbol etc (see bug 94319). Are you using it '<font face="....">'
or in '<span style='font-family: ....'>? Only the former works (thanks to the
patch for bug 94319) and the latter does NOT work. The latter will NEVER be made
to work. For the latter, you have to use the proper Unicode code points for
extended Greek letters. 

 BTW, 'Symbol' font issue is bug 195038 (on MS Windows). 
Those of you who have been wishing to see something happen will be happy to know
that bug 195038 now has a fix for Windows.

It makes <font face="Symbol">...</font> to "work" like the other 
<font face="Webdings">...</font> and friends, in quirks mode. That is, <font
face="Symbol">a</font> gives alpha. Hopefully, this will cut the stream of
complaints that developers are out of touch with the reality.

<span style="font-family: Symbol">...</span> remains the standards way.
Depends on: 195038
Depends on: 208213
*** Bug 252287 has been marked as a duplicate of this bug. ***
*** Bug 256017 has been marked as a duplicate of this bug. ***
*** Bug 262494 has been marked as a duplicate of this bug. ***
*** Bug 263623 has been marked as a duplicate of this bug. ***
I have to comment on this, because it's just the most braindead thing I've seen
in Mozilla, and it's really p***ed me off today because now I'm going to have to
use images to get the symbol I want increasing the load on my server, losing
flexability in terms of size & colour of the symbol, and generally just being
really really stupid.

When I say in CSS 
.foo { font-family:webdings; }
and webdings is available to the client (which perhaps the developer has the
capability to ensure, such as I do) I expect that unless the user has explicitly
overridden fonts that webdings will be used.

Webdings contains symbols not available in Unicode (example, &#050; in webdings,
you tell me where that is in Unicode), currently these seem to be unavailable in
Mozilla Windows (in standards mode at least, there appears to be no way to
display webdings at all) - again, Linux at least has no problem with
font-family:webdings;.

The reality is that webdings is a very useful font, and the developers in thier
infinite wisdom have effectivly put it out of reach on Windows.
By "&#050; in webdings" I assume you mean "0x32 in Webdings", since "&#050;" is
U+0032 DIGIT TWO in any font ("&#050" means "character decimal 50 in the Unicode
character set", which is a "2").

To answer your question, it appears Unicode doesn't have a glyph for overlapping
windows. And therefore the correct thing to do is to not use a glyph. It doesn't
matter that on some platforms there happens to be a proprietary font that can
display a glyph that has the appearance you are looking for. The Web is a
Unicode medium, and therefore only Unicode characters can be represented using
characters.
Okay, I just spent a fair bit of time reading through this bug, and I feel like it's worth posting a short summary for posterity.  Hopefully this won't overly tempt anyone to restart old debates.

Salient points of this bug:

 - The proper way to embed textual symbols in HTML documents is to use Unicode.

 - Unicode works differently from the way most people are used to thinking of fonts.  You don't write the text in your system font and then tell the browser to display it differently.

 - There are two ways to put a Unicode character in your document:
 -- First, you can write the HTML using a Unicode-enabled text editor, either compose the character, or to cut and paste it from another document.
 -- Second, you can use the &#nnnn; entities to enter the Unicode symbol's number.

 - http://www.alanwood.net/demos lists some Unicode equivalents to Symbol and Wingdings fonts.  I don't know if such a resource exists for Wingdings 2 or other fonts.

 - Many Symbol and Wingdings glyphs do not have Unicode equivalents.  It is simply not possible to use those glyphs in a standards-compliant document, and they will probably not be rendered the way you intended when Mozilla is in standards-compliance mode.

 - There is a workaround quirk implemented in Mozilla:  If Mozilla is in Quirks mode, <font face="Wingdings">...</font> will probably do what you want, but will not be standards-compliant.  This quirk will not work through CSS.

And as a personal observation, I do think that there was a lot of talking past each other between the purist and pragmatic camps here.  The purists may be "right" (at least from a legal standpoint), but I think it's also important to recognize that this answer is going to frustrate a lot of people, due to both the unavailability of some system-specific glyphs, and the relative awkwardness of composing the Unicode.
I think we need to take a serious look at this issue again.  I don't believe our current behavior is the desired behavior for anyone.

if someone has <span style="font-family: Wingdings 2">asdf</span> then they have pretty clearly asked for that font and the code points to be rendered with that font.  Substituting another font in place when the author has clearly asked for a font that is on ones system is pretty busted.  I suppose ideally we could specify something like a user defined charset for the individual element so that we would know, more explicitly, that the user doesn't want to treat the contents as UCS.

I understand that many of these fonts are platform specific and I don't think we should promote them, however I believe that treating which font you ask for as a quirk is a huge mistake.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
We shouldn't be in the business of encouraging people to write platform-specific Web pages.  The current behavior is a compromise -- we have a quirk that keeps the bulk of the existing pages that depend on this behavior working on the platforms that have the fonts in question, but doesn't let authors writing modern Web pages accidentally depend on them.

Calling it reopened (from invalid) is also a bit disingenuous -- you actually already fixed it without telling anyone, as far as I can tell.
Status: REOPENED → RESOLVED
Closed: 22 years ago17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: