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)
Core
CSS Parsing and Computation
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...
Comment 1•24 years ago
|
||
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
Reporter | ||
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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 → ---
Updated•24 years ago
|
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
Comment 4•24 years ago
|
||
Marking INVALID. See previous comment.
Reporter | ||
Comment 5•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
Works for Me Mozilla renders it correctly. Platform: PC OS: Windows 98 Build # 2000100508 M18 Trunk Build Marking as Verified
Status: RESOLVED → VERIFIED
Comment 10•24 years ago
|
||
Does this apply to characters > 127?
Comment 11•24 years ago
|
||
Jesse, this applies to all characters.
Comment 12•24 years ago
|
||
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)?
Reporter | ||
Comment 13•24 years ago
|
||
Erik - this does beg the question "How does one actually use Symbol font"? Gerv
Comment 14•24 years ago
|
||
In Mozilla, you can use the "Symbol" font if you code the text appropriately, e.g. a Greek charset, or Greek entities such as α. 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.
Comment 15•24 years ago
|
||
*** Bug 34940 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
*** Bug 62234 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
The symbol font is essential to scientists! Fix this ASAP.
Assignee | ||
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
*** Bug 66333 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
*** Bug 75387 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
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)?
Comment 25•23 years ago
|
||
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> β is a Greek beta or β in unicode ⟨ is a left angle bracket or 〈 in unicode </body> </html>
Comment 26•23 years ago
|
||
*** Bug 78929 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
See also bug 77265, "Wingding symbol font not rendering in Mail".
Comment 28•23 years ago
|
||
*** Bug 99268 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
*** Bug 100621 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
*** Bug 101405 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
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?
Comment 32•23 years ago
|
||
>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
Comment 33•23 years ago
|
||
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.
Comment 34•23 years ago
|
||
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).
Comment 35•23 years ago
|
||
UTF8 does NOT have all the characters in the symbol set. That is the problem.
Comment 36•23 years ago
|
||
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.
Assignee | ||
Comment 37•23 years ago
|
||
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 α.
Comment 38•23 years ago
|
||
CCd ftang who, wrong or right, seems enclined to look at another strategy under bug 104531.
Comment 39•23 years ago
|
||
IE's online help knowledge base does not have ANY references to Unicode or ISO 10646. The α 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?
Comment 40•23 years ago
|
||
Moreover the α 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 α will crash mozilla 0.95 on the spot;-(
Comment 41•23 years ago
|
||
*** Bug 104531 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
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
Comment 43•23 years ago
|
||
> 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)
Comment 45•23 years ago
|
||
> 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.
Comment 46•23 years ago
|
||
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.
Comment 47•23 years ago
|
||
I see. So you care exclusively about the Windows platform?
Comment 48•23 years ago
|
||
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.
Comment 49•23 years ago
|
||
Comment 50•23 years ago
|
||
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).
Comment 51•23 years ago
|
||
Comment 52•23 years ago
|
||
+/- is in unicode: in fact, it's in ISO8859-1! ± As is -/+ (⁑). 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?
Comment 53•23 years ago
|
||
[ Moreover the α 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 α 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 α entity doesn't work in Netscape 4.78 for Windows, true, but the corresponding numeric entity &#945; does.
Comment 54•23 years ago
|
||
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.
Comment 55•23 years ago
|
||
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
Comment 56•23 years ago
|
||
> 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)
Comment 57•23 years ago
|
||
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
Comment 58•23 years ago
|
||
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
Comment 59•23 years ago
|
||
> 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.
Assignee | ||
Comment 60•23 years ago
|
||
On what other non-Windows browsers does this symbol font trick "work"?
Comment 61•23 years ago
|
||
>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.
Comment 62•23 years ago
|
||
> 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 α t - m α 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.
Comment 63•23 years ago
|
||
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.
Comment 64•23 years ago
|
||
> 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!
Comment 65•23 years ago
|
||
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.
Comment 66•23 years ago
|
||
(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.
Comment 67•23 years ago
|
||
I like that solution. It tried to do my last newsletter in Unicode, and all the greek letters (ρ ) 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.
Comment 68•23 years ago
|
||
James: have you tried using numeric entity references (i.e., ρ rather than ρ)? I believe these are better supported than the named HTML 4 entity references in old browsers. The Unicode symbol you mentioned is ≈ "ALMOST EQUAL TO".
Comment 69•23 years ago
|
||
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 :-)
Comment 70•23 years ago
|
||
> 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.
Comment 71•23 years ago
|
||
> 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.
Comment 72•23 years ago
|
||
>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.
Comment 73•23 years ago
|
||
> 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.
Comment 74•23 years ago
|
||
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 |α| or |α|. 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
Comment 75•23 years ago
|
||
>> 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.
Comment 76•23 years ago
|
||
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 α and co.
Comment 77•23 years ago
|
||
> pop up a window the first time mozilla hits a page which uses the symbol font
No.
Comment 78•23 years ago
|
||
> 2) Feel free to remove the code once 90% of the browsers in use support > α 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 |α| or |α|. 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?
Comment 79•23 years ago
|
||
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?
Comment 80•23 years ago
|
||
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.
Comment 81•23 years ago
|
||
>> 2) Feel free to remove the code once 90% of the browsers in use support
>> α 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)!
Comment 82•23 years ago
|
||
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 >>> α and co. >> they do. > I'm giving up. What part of my statement are you challenging? That IE doesn't support α 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?
Comment 83•23 years ago
|
||
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.
Comment 84•23 years ago
|
||
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 α It is not Mozilla's mission to change the world IMHO.
Comment 85•23 years ago
|
||
Could you show us the page you were having trouble with?
Comment 86•23 years ago
|
||
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.
Comment 87•23 years ago
|
||
> 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?
Comment 88•23 years ago
|
||
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
Comment 89•23 years ago
|
||
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.
Comment 90•23 years ago
|
||
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?
Comment 91•23 years ago
|
||
> 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 α 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 α. 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.
Comment 92•23 years ago
|
||
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
Comment 93•23 years ago
|
||
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
Comment 94•23 years ago
|
||
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?
Comment 95•23 years ago
|
||
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.
Comment 96•23 years ago
|
||
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).
Comment 97•23 years ago
|
||
*** Bug 114737 has been marked as a duplicate of this bug. ***
Comment 98•23 years ago
|
||
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.
Comment 99•23 years ago
|
||
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.
Comment 100•23 years ago
|
||
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.
Comment 101•23 years ago
|
||
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.
Comment 102•23 years ago
|
||
> 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.
Comment 103•23 years ago
|
||
That's no worse than what happens on Latin1 pages, which is IMHO not a big deal.
Comment 104•23 years ago
|
||
> 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.
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
> 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.
Comment 107•23 years ago
|
||
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.
Assignee | ||
Comment 108•23 years ago
|
||
> 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.
Comment 109•23 years ago
|
||
> 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.
Comment 110•23 years ago
|
||
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.
Comment 111•23 years ago
|
||
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.)
Comment 112•23 years ago
|
||
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.
Comment 113•23 years ago
|
||
If people care more about looks than structure then they *should* be using PDF.
Comment 114•23 years ago
|
||
*** Bug 121358 has been marked as a duplicate of this bug. ***
Comment 115•23 years ago
|
||
Moving to mozilla1.1. Engineers are overloaded!
Target Milestone: mozilla1.0 → mozilla1.1
Comment 116•22 years ago
|
||
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
Assignee | ||
Comment 117•22 years ago
|
||
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)
Comment 118•22 years ago
|
||
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).
Comment 119•22 years ago
|
||
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).
Comment 120•22 years ago
|
||
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.
Assignee | ||
Comment 121•22 years ago
|
||
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".
Comment 122•22 years ago
|
||
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.
Comment 123•22 years ago
|
||
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.
Comment 124•22 years ago
|
||
Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1
Comment 125•22 years ago
|
||
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.
Comment 126•22 years ago
|
||
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
Updated•22 years ago
|
Whiteboard: either WONTFIX or see comment 119
Comment 128•22 years ago
|
||
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.)
Comment 129•22 years ago
|
||
cc'ing myself
Comment 130•22 years ago
|
||
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 α 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.'
Assignee | ||
Comment 131•22 years ago
|
||
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."
Comment 132•22 years ago
|
||
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.
Comment 133•22 years ago
|
||
I feel compelled to weigh in again with Bruce, who wrote: ... The escape codes such as α 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.)
Comment 134•22 years ago
|
||
*** Bug 145052 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 135•22 years ago
|
||
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: REOPENED → NEW
Priority: P1 → P3
Comment 136•22 years ago
|
||
*** Bug 159595 has been marked as a duplicate of this bug. ***
Comment 137•22 years ago
|
||
Obs to comment #122: Look at the page mentioned in bug #159595 (marked as duplicate to this one) for an example using styles.
Comment 138•22 years ago
|
||
*** Bug 163300 has been marked as a duplicate of this bug. ***
Comment 139•22 years ago
|
||
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
Assignee | ||
Comment 140•22 years ago
|
||
ok, marking as such
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → INVALID
Comment 141•22 years ago
|
||
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."
Comment 142•22 years ago
|
||
*** Bug 166090 has been marked as a duplicate of this bug. ***
Comment 144•22 years ago
|
||
*** Bug 166843 has been marked as a duplicate of this bug. ***
Comment 145•22 years ago
|
||
*** Bug 94319 has been marked as a duplicate of this bug. ***
Comment 146•22 years ago
|
||
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 → ---
Comment 147•22 years ago
|
||
*** Bug 172280 has been marked as a duplicate of this bug. ***
Comment 148•22 years ago
|
||
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.
Comment 149•22 years ago
|
||
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.
Comment 150•22 years ago
|
||
*** Bug 177238 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Alias: symbol
Assignee | ||
Comment 151•22 years ago
|
||
*** Bug 185736 has been marked as a duplicate of this bug. ***
Comment 152•21 years ago
|
||
*** Bug 193596 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 153•21 years ago
|
||
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.
Comment 154•21 years ago
|
||
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.
Comment 155•21 years ago
|
||
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.
Comment 156•21 years ago
|
||
See http://bugzilla.mozilla.org/show_bug.cgi?id=94319#c90 for more on the compliant usage and why it is important.
Comment 157•21 years ago
|
||
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 α 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?
Comment 158•21 years ago
|
||
> unless i'm reading something wrong, the fix proposed only applies when
> α and the like are NOT present
You're reading something wrong.
Comment 159•21 years ago
|
||
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?
Comment 160•21 years ago
|
||
"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.
Comment 161•21 years ago
|
||
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.
Comment 162•21 years ago
|
||
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.
Comment 163•21 years ago
|
||
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.
Comment 164•21 years ago
|
||
*** Bug 210529 has been marked as a duplicate of this bug. ***
Comment 165•21 years ago
|
||
*** Bug 209672 has been marked as a duplicate of this bug. ***
Comment 166•21 years ago
|
||
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.
Comment 167•21 years ago
|
||
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).
Comment 168•21 years ago
|
||
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
Comment 169•20 years ago
|
||
*** Bug 252287 has been marked as a duplicate of this bug. ***
Comment 170•20 years ago
|
||
*** Bug 256017 has been marked as a duplicate of this bug. ***
Comment 171•20 years ago
|
||
*** Bug 262494 has been marked as a duplicate of this bug. ***
Comment 172•20 years ago
|
||
*** Bug 263623 has been marked as a duplicate of this bug. ***
Comment 173•19 years ago
|
||
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, 2 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.
Comment 174•19 years ago
|
||
By "2 in webdings" I assume you mean "0x32 in Webdings", since "2" is U+0032 DIGIT TWO in any font ("2" 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.
Comment 175•17 years ago
|
||
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.
Comment 176•17 years ago
|
||
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 → ---
Assignee | ||
Comment 177•17 years ago
|
||
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.
Assignee | ||
Updated•17 years ago
|
Status: REOPENED → RESOLVED
Closed: 22 years ago → 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•