Home / Pete's stuff / Not computer games / Browser symbol tests

Contact site author

Updated 2005-10-25

Symbol Display Tests for Web Browsers

CSS functionality missing: This site will appear closer to the author's intent in a browser that supports web standards, but it is accessible to any browser or Internet device. If you can read this, CSS (style sheets) is essentially disabled on this page, thus degrading the presentation but not losing any content. That's due to either the CSS file being unavailable from the server, your browser failing to understand it, or viewing in a medium besides a browser screen.

Been Framed?

If this page is displayed in a frame, which should happen only when the Geocities/Yahoo server puts them there and not because some other site is displaying my content, please reload this page to bust out of them.

Page Purpose

This page was built to test several web browsers for proper display of some foreign-language, purely symbolic and punctuation (em dash, en dash, horizontal ellipsis) glyphs needed by my other web pages. I'm trying to see what other users would see, so I'm making only the changes available to an HTML editor, i.e. no server directives (which I can't do on Geocities/Yahoo anyway, right?). The symbol/character/glyph/entity terminology I'm using is probably wrong, but it's all rather confusing to somebody like me who's just trying to make things "look right."

Currently directly testing with Microsoft Internet Explorer 6.0 (6.0.2800.1106 & 1106CO) and Netscape Communicator 7.01. Browsers running under Windows 2000 (Version 5.0, Build 2195: Service Pack 4) (IE 6.0.2800.1106CO), Windows XP Pro (Version 5.1 Build 2600) (IE 6.0.2800.1106) and Windows ME (Netscape 7.01 and IE 6.0). Language preferences set to en-us, en, en-gb, then fr. No special internationalization done for browsers, e.g. loading fonts or setting different Windows input locales. Attempting to use only Symbol and Arial fonts by name. Base language of en-US set as HTML attribute. Character set is specified with XML and META elements. Note: the user's switching to another one in IE 4.0 or Netscape 4.72 (approximate earliest version) doesn't work if one is set in the HTML. If there was any significant difference in appearance between default character set (ISO-8859-1) and UTF-8, it is noted below.

Some of the entity references (things like &agr;) are supposedly SGML and may not work in HMTL. These were found on technical publishing sites along with references to ISO-8879. But they're worth a shot…

Font forcing is bad. Font forcing is evil. But I did it here, because when I first started doing this in 2001, it was sometimes the most universal solution available. "Symbol" should be available on every non-Greek computer that has a reasonable hope of rendering a lowercase alpha. "Arial" on the other hand, is just there to be annoying, and it's one of the few short font names that I know that should be on both PCs and Macs. Symbol is the one I'm really interested in. Therefore, when I'm specifically asking for the Arial font, the fact that what comes out is incongruous compared to the default font nearby will pass without comment. It would be noticeable if you were using font forcing within a word. I'll say it's not recommended for my intended use (properly showing occasional non-English glyphs in English text), especially since the entity reference usually works well.

The "done with" rows in the tables below contain some extra space characters that aren't in the implementation rows above them. These spaces are just there to make the contents of the table cells "line break" better. You may notice some strange situations though, such as a line break between "&" and "#x1234;" even though there is a convenient space just before the "&". Sigh… Also, the implementations are all in lowercase now as required by XHTML 1.0.

Windows has an Accessory called Character Map that allows you to directly insert strange characters into documents, or tells you the keystrokes so you can do it yourself. Unfortunately, using this for some characters doesn't work too well, especially if the symbol isn't supported in other fonts, and it will break a SGML-based validator. So, I'm not using Character Map at all, in favor of the HTML named and numbered entities. The Character Map stuff also often breaks under the UTF-8 character set.

Updates

• 2001-03-08: An OS upgrade from Windows 95b to NT 4.0 on the computer that I use for testing IE 4 has produced some interesting changes. In general, due solely to the OS itself or the fonts in it, Unicode support has visibly improved, and some "incongruous font" entries are now gone. However, I haven't done "regression" testing of character codes 8592-8595, or character set switching to UTF-8.
• 2002-01-17: IE 5.5 was found to have a few minor improvements compared to 5.0. But the "up arrow" is still broken in the Symbol font. Netscape 4.78 is no better than 4.75, even under Windows ME.
• 2002-03-18:
  I'm no longer able to test against MsIE 4.0, so I've deleted mention of that browser; it's obsolete anyway, and you should have updated to at least 5.5 by now.
  This page was converted to XHTML 1.0, so I had to choose a character set for this page; so I went with ISO-8859-1. UTF-8 doesn't like the inserted characters from the Windows Character Map.
  Also discovered that hexadecimal numerical entity references are no longer valid with uppercase X, as in [ILLEGAL EXAMPLE: "ᨫ"], so they were all removed. But you can apparently use either case for the hexadecimal value, e.g. x1A2b = x1a2B = x1A2B = x1a2b to the validator and IE 5.5. And also that the decimal numerical entity references are deprecated, as are the named entity references, but I left them in for now.
  The behavior of the PRE element in IE4 was rather strange: the lowercase alpha character is correctly displayed within it when using the named entity reference, but never otherwise. Why? (In English, <PRE>&alpha;</PRE> looked OK.) However, using this always added a blank line when going either in or out of PRE. Therefore, this made it only a curiosity, and not of practical use. Also, the font used appears consistently smaller and looks more like typewriter output in the 3 browsers that I tested. So, I've removed the PRE "test" for all but the lowercase alpha.
  Removed most of the MATH tags, which never had any apparent effect except causing validator errors.
• 2002-03-19: Added another letter to the "should also be tested" area, added hexadecimals to that area for known decimals. Tested with Netscape 4.78, and entered the results. Upgraded to 4.79, no changes to results.
• 2002-03-21: Got MsIE 6.0, but the results are exactly the same as 5.5.
• 2002-03-22: Netscape 6.2.2 tested. I'm keeping Netscape Communicator 4.79 installed until I'm sure I've moved a bunch of old emails, so I won't be deleting those test results right away. But I will be changing what I'm supporting based on these two "6.x" browsers; font forcing is going away except for the tests on this page. I'm going to consign Netscape Communicator 4.7 to the level of hell set aside for bad browsers. No more font forcing for me, I promise!
• 2002-03-31: Tested IE 6 under Windows XP Pro, noticed a few rendering differences. I'm hoping these are due to fonts rather than the browser being different than for Windows 2000.
• 2002-06-01: I'll no longer be maintaining the Netscape 4.79 results, as you shouldn't be using such an old browser when you can get version 6 or MsIE for free. What remains of the 4.79 results will stay, but I won't base my conclusions on them anymore.
• 2002-11-02: I'll no longer be maintaining the Internet Explorer 5.5 results, as you shouldn't be using such an old browser when you can get MsIE version 6 for free. What remains of 5.5 test results will stay, but I won't base my conclusions on them anymore. Added obvious link to the WaSP site.
• 2002-12-28: Removed lots of stuff about Netscape 4.7, added stuff about version 7; you should upgrade your browser instead of using 4.7. Rewrote the overall evaluation.
• 2002-12-31: Netscape upgraded to 7.01, dropped maintenance of version 6 results. The old results will stay, but I won't base my conclusions on them anymore. Dropped Netscape 4.7 results completely and conclusions based on them; you should have upgraded to at least version 6 by now. Fixed up mention of Bobby site. Fixed code to improve XHTML 1.1 validation by taking out inserted accented characters, but stayed at 1.0 until I figure out how to handle the changes caused by the strictness of the 1.1 DTD. Dropped my attempt to do MathML.
• 2003-01-04: More code and text cleanup. Standardized on both an xml:lang and a lang declaration. Using &#160; instead of the supposedly equivalent alternates. Added horizontal ellipsis.
• 2004-09-30: It's been over a year since they were forced on me, but I finally admit that I've unavoidably still got access to IE 5.5 (5.50.4807.2300CO) and Netscape 4.76, both under Windows 2000 SP4. Pity me.
• 2005-03-25: Finally, the IE available under Windows 2000 was upgraded to 6.0.2800.1106CO, but the Netscape is still at 4.76 and obviously of no use to anyone (it hangs on the default home page they provided!). IE 5.5 results will no longer be maintained.
• 2005-08-20: Now using &#xA0; instead of the supposedly equivalent 160 or nbsp throughout my site.
• 2005-09-15: My Windows ME access has been gone for several months and is unlikely to return. Rearranged some content, and rewrote updates and overall conclusions.
• 2005-10-25: Added two named entities in the punctuation section, two browser download links in overall evaluation. Fixed capitalization of a game console name. First noticed tall and normal box symbols in IE 6.0. Fixed table headings. Separated out IE 6 under Windows XP Pro when it produced different results.

Useful sites elsewhere:

• Character codes obtained from the Unicode standard site.
• The Web Standards Project is a good site to find resources elsewhere. All these guys seem to do is whine, though.
• The W3C or World Wide Web Consortium where HTML and now XHTML recommendations come from.
• The W3C Validator says the pages on my site are good XHTML 1.0 Transitional, except for the stuff the Geocities/Yahoo server tacks on after my </html>, and the symbol stuff on this page.
• Bobby accessibility/compatibility checker is just what it says.
• The Index DOT HTML site is of unknown vintage (mentions HTML 4.0 but not 4.01 or XHTML) but still useful regarding showing symbols properly.
• The WDG Web Authoring FAQ covers a lot of ground and is pretty current.
• Robin's HTML 4.0 Conformance Test is also reasonably current and has links to other test sites.
• The Web Standards Project encourages you to download a free browser that complies with World Wide Web standards, but their browser update campaign is done.

Switching Character Sets

The recommended thing to do with "web pages" is to set a character set in a META element near the top of the HEAD section. In fact, that declaration should appear before even the TITLE tag, in case there's something strange in the TITLE text. However, there are 2 problems with doing that:

1. Some web browsers don't actually change the character set if it's set in the HTML element, then the user sets it to something different. Apparently, the META setting overwrites what the browser is doing, and nothing changes on the screen. Problem seen with Netscape 4.72 and IE 4, probably IE 5 as well.
2. If the character set in the META element is UTF-8, IE 4 will crash when you try to invoke an internal link on the same page, e.g. <a href="#on_this_page">jump to somewhere else on this page</a>. This may be only when the page is local, i.e. on your computer's hard drive, but since people can save HTML source from websites rather easily, the problem can occur anywhere even if it doesn't on the web server.

My decision: Since IE 4 is obsolete, and I can't get away with not putting a character set on a page anymore (validation for XHTML 1.0 requires it), it's been ISO-8859-1 for me for quite a while. All my web pages that might have a problem with displaying strange symbols should link to this symbol test page. While I'll try to provide a reasonably complete discussion of the problem, I've had to pick my way of solving it already.

Interested readers (all of you who haven't already left, I hope) can still try to change their "character encoding" or "font" to see if it makes a difference. In Netscape and Internet Explorer, the Character Encoding/Character Set/Font setting is in the View menu. You should be able to leave that setting where it is throughout my site, but I'll warn you that you may see some strange behavior regardless.
First, bad old Netscape 4.7 put boxes between each character that isn't normal text size, e.g. in headings, while loading pages that are set to display in some other character set than the default, then they suddenly disappeared when the page was loaded. Visually annoying, but only cosmetic and temporary. You can get around this by setting your browser back to its original setting when you're done with my pages.
Second, you may get unpredictable things when you visit web pages elsewhere that have done bizarre things with specifying the character set used by that page. I apologize for the confusion this may cause, but here's hoping it's only temporary. When everybody's way of viewing web text content has proper internationalization (i18n)/Unicode/UTF-8/ISO-10646 support, all this will be a bad memory.

Foreign Glyph Tests

The following tests are for foreign language glyphs used on other web pages on this site. The languages include Greek, French, Spanish, Portuguese, romanized Japanese, and Polish.

α

&agr; and &b.alpha; are SGML and probably won't work in HTML.
Switching to UTF-8 makes Netscape 4.7 marginally better. The "Unicode in decimal" column becomes "CORRECT SYMBOL FOLLOWED BY ? DISPLAYED", and the "Unicode in hexadecimal" column becomes "CORRECT SYMBOL DISPLAYED 4 TIMES, 2 BOX SYMBOLS DISPLAYED" (that one just like IE5!).
Sorry, Netscape 4.7 and other bad browser users, I had to code to the standard.
IE 6.0 now has two different box symbols that appear when it can't display a Unicode character. One is noticeably taller than another, so they're called TALL BOX SYMBOL and BOX SYMBOL in the table above. I have no idea if there's any real difference between them, or exactly what made them start showing up for me on 2005-10-25.
The PRE thing is there just as a curiosity; it was the ONLY way to get IE 4 to show the correct symbol, but it has too many disadvantages.

WHERE USED: (in all cases to refer to my twice-removed alternate history timeline)

• Pete's Draka page.
• Draka 2alpha Timeline index page.
• Draka 2alpha Timeline 1652–1815
• Draka 2alpha Timeline 1815–1916
• Draka 2alpha Timeline 1917–1939
• Draka 2alpha Timeline 1940–1948+
• Draka 2alpha Timeline: 1940 (The Second Great War) page.
• Draka 2alpha Timeline: 1942 (The Second Great War) page.
• Draka 2alpha Timeline: 1943 (The Second Great War) page.
• Small Arms Development in the Draka 2alpha Timeline page.
• Draka 2alpha Timeline: Q and A page.
• Draka 2alpha Timeline: Items in Progress page.
• Draka 2alpha Timeline Commentary page.
• Appendix 15: Small Arms Development for the original Draka timeline.
• What WAS New for the Karsanow pages.
• What's New for Pete Karsanow's pages!.

CONCLUSION:
The named entity (for readability) or the #x3B1 numerical entity in hexadecimal (preferred) is the way to go. It even appears reasonable in the window title, when placed in the title attribute within the head section of a page.

There used to be a second "lowercase a tilde" character in the "language-declared" implementation, inserted from the Windows (95 and later) Character Map Accessory. It's Alt+0227 in most fonts. While this has been used by others, it is a BAD idea! First, it breaks badly under UTF-8. The tested browser's parsers usually took the inserted character plus the next two characters, and treated them together as a box symbol, or just rendered a box. Netscape 6 showed a "?". Yuck! Second, it breaks the W3C XHTML Validator, as the inserted character is invalid in the default character set, and causes the entire file to be rejected!
The "a&#x303;" construct is using the combining tilde accent from Unicode.
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations.

WHERE USED:

• Draka 2alpha Timeline 1815–1916 page to refer to islands off Africa.
• "How I Damned the World" timeline page to refer to those same islands off Africa.

CONCLUSION:
For lowercase a tilde, use the named entity. I really should check if it works properly inside a language declaration though…

The "e&#x301;" construct is using the combining acute accent from Unicode.
There used to be a second "lowercase e acute" character in the "other" column, inserted from the Windows 95 Character Map Accessory (Alt+0233 in most fonts). While this has been used by others, it is a BAD idea! First, it breaks badly under UTF-8. The tested browser parsers usually took the inserted character plus the next two characters, and treated them together as a box symbol, or just rendered a box. Netscape 6 showed a "?". Yuck! Second, it breaks the W3C XHTML Validator, as the inserted character is invalid in the default character set, and causes the entire file to be rejected!
Switching to UTF-8 makes both IE 4 and 5 marginally (and identically) worse. The inserted (from the Character Map accessory) "lowercase e acute" character (Alt+0233 in most fonts) is displayed erroneously with the end of the TD closing element as a box symbol followed by "td>". Strangely, the table cell and row appear to complete rendering correctly regardless. IE 6 is even stranger; it shows a Chinese glyph instead of the box.
Switching to UTF-8 made Netscape 4.7 show a box symbol instead of the inserted character; Netscape 6 showed a "?".
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations.
&Eacute; (uppercase e acute) should be supported just as well as the lowercase one; see below for that one.

WHERE USED:

• Draka 2alpha Timeline 1652–1815 page to refer to a region of Canada and islands off Africa.
• Draka 2alpha Timeline 1815–1916 page to refer to islands off Africa and a historical French inventor.
• Draka 2alpha Timeline: 1940 (The Second Great War) page to use a French loan word for an official announcement or report, usually sent in haste.
• Small Arms Development in the Draka 2alpha Timeline to refer to an historical French invention by the inventor's name.
• Pete's Drakon/Batman fanfic: "A Drakon in Gotham" to refer to a Hispanic minor character by name.
• "A Connecticut Yankee in the Archon's Court" Chapter 1 page to use a French loan word for one promoted and protected by another in power.
• "A Connecticut Yankee in the Archon's Court" Chapter 2 page to use a French expression for a diplomatic condition.
• "A Connecticut Yankee in the Archon's Court" Chapter 3 page to use a French loan word for a trite or hackneyed expression.
• "How I Damned the World" timeline page to refer to those same islands off Africa, and that same French inventor.
• my home page and several others still in development, to use a French loan word for a summary of work experience.
• Legend of Legaia demo page because it links to the page with the manual for the game with the popular little monsters.
• Pete's non-computer-games page because it links to the page with the manual for the game with the popular little monsters.
• Pete Karsanow's Console Role-Playing Games Stuff to refer to a GameBoy game.
• Pokemon Manual page to refer to those popular little monsters, using both upper- and lowercase e acute.
• Site Map page because it links to the page with the manual for the game with the popular little monsters.
• What's New for Pete Karsanow's pages! to refer to a GameBoy game and the changes to the above pages.
• What WAS New for the Karsanow pages to refer to a GameBoy game, a region of Canada, and the changes to the above pages.

CONCLUSION:
For lowercase e acute, use the named entity. Seems to works properly inside a language declaration too. The numerical one might save a byte or two.

The "i&#x301;" construct is using the combining acute accent from Unicode.
There used to be a second "lowercase i acute" character in the "other" column, inserted from the Windows 95 Character Map Accessory (Alt+0237 in most fonts). While this has been used by others, it is a BAD idea! First, it breaks badly under UTF-8. The tested browser parsers usually took the inserted character plus the next two characters, and treated them together as a box symbol, or just rendered a box. Netscape 6 showed a "?". Yuck! Second, it breaks the W3C XHTML Validator, as the inserted character is invalid in the default character set, and causes the entire file to be rejected!
Switching to UTF-8 makes IE 4, 5 and 6 marginally (and identically) worse. The inserted (from the Character Map accessory) "lowercase i acute" character (Alt+0237 in most fonts) is displayed erroneously with the end of the TD closing element as a box symbol followed by "td>". Strangely, the table cell and row appear to complete rendering correctly regardless.
Switching to UTF-8 makes Netscape 4.7 show a box symbol instead of the inserted character; Netscape 6 shows a "?".
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations, in fact it doesn't replace the dot over the "i".

WHERE USED:

• Draka 2alpha Timeline 1815–1916 page to refer to islands off Africa.
• "How I Damned the World" timeline page to refer to those same islands off Africa.

CONCLUSION:
For lowercase i acute, use the named entity. Seems to work properly inside a language declaration too.

&omacr; and &ohbar are SGML and probably won't work in HTML.
The "o&#x304;" construct is using the combining macron from Unicode.
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Actually, not used anywhere on my site yet. If I go a little further on my twice-removed alternate history though, I expect that I'll need some Japanese place names.

CONCLUSION:
For lowercase o macron, use &#x14D;, preferably with the entire word inside a Japanese language declaration. Declare UTF-8 character set for the page if possible.

&umacr; is SGML and probably won't work in HTML.
The "u&#x304;" construct is using the combining macron from Unicode.
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Actually, not used anywhere on my site yet. If I go a little further on my twice-removed alternate history though, I expect that I'll need some Japanese place names.

CONCLUSION:
For lowercase u macron, use &#x16B;, preferably with the entire word inside a Japanese language declaration. Declare UTF-8 character set for the page if possible.

&sacute; is SGML and probably won't work in HTML.
The "s&#x301;" construct is using the combining acute accent from Unicode.
In Netscape 6 and 7, the combining accent isn't as low as it appears on the other representations.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Draka 2alpha Timeline: 1943 (The Second Great War) page to refer to a Polish village near an infamous German place name.

CONCLUSION:
For lowercase s acute, use &#x15B;, preferably with the entire word inside a Polish language declaration. Declare UTF-8 character set for the page if possible.

This character isn't in ISO-8859-1, you have to use ISO-8859-2 to get it "natively".
The "e&#x328;" construct is using the combining ogonek from Unicode.
In Netscape 6 and 7, the combining accent isn't centered like it appears on the other representations.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Draka 2alpha Timeline: 1943 (The Second Great War) page to refer to a Polish village near an infamous German place name.

CONCLUSION:
For lowercase e ogonek, use &#x119;, preferably with the entire word inside a Polish language declaration. Declare UTF-8 character set for the page if possible.

I'm using a few more foreign-language symbols too, but these are believed in common enough usage elsewhere that they aren't tested in the exhaustive table form as used above.

WHAT & WHERE USED:

• As mentioned above, É (uppercase e accent acute, named entity &Eacute; — note the capital letter!) is used on my Pokémon Manual page in the name of a popular video game franchise of little monsters. Using the numbered entity syntax &#201; gives you É in decimal, &#xC9; gives you É in hexadecimal.
• Draka 2alpha Timeline: 1816–1915 page has one use of ç (lowercase c cedilla, named entity &ccedil;) for the French word façade. Using the numbered entity syntax, &#231; gives you ç in decimal, &#xE7; gives you ç in hexadecimal.
• Draka 2alpha Timeline: 1816–1915 page also needs one á (lowercase a acute, named entity &aacute;) for the Mexican city name Ciudad Juárez. Using the numbered entity syntax, &#225; gives you á in decimal, &#xE1; gives you á in hexadecimal.
• Draka 2alpha Timeline: Q and A page has one use of è (lowercase e accent grave, named entity &egrave;) for the French word crèche. Appendix 13: Land Tenure & Plantation Life is the same, and Appendix 9: Economics & The Standard of Living uses the plural of the word. Using the numbered entity syntax &#232; gives you è in decimal, &#xE8; gives you è in hexadecimal.
• "A Connecticut Yankee in the Archon's Court" Chapter 1 page has one use of ñ (lowercase n tilde, named entity &ntilde;) for the Spanish word señorita. Using the numbered entity syntax &#241; gives you ñ in decimal, &#xF1; gives you ñ in hexadecimal.
• Pete's Hentai Games List/Table page refers to a game called "Möbius Röid". This has two uses of ö (lowercase o umlaut or lowercase o diaeresis, named entity &ouml;). It's also used in a reference to a well-known quantum physics paradox in Chapter 2 of my "Connecticut Yankee" fanfic. Using the numbered entity syntax &#246; gives you ö in decimal, &#xF6; gives you ö in hexadecimal.

Symbol Tests

The following tests are for purely symbolic glyphs used on other web pages on my site. These include a square, triangle, circle, and arrows. There is no real "language" for them (those who say there's MathML can send me working examples). The 4 arrows are to indicate game controller directions, but are using formal mathematical symbols. The arrows, and the open circle, triangle, square and san-serif X, are all useful for PlayStation games. Several others symbols are only tested in a "short" form.

Font forcing Symbol to the Unicode 8592 decimal is a BAD idea. In IE4 it produced an invisible character about 900 pixels wide!
Netscape 6 and 7 show something like an en dash with a short vertical bar dangling down from the right end. Whatever it is, it's not what I want.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Legend of Legaia Demo FAQ page to display a PlayStation directional button.

CONCLUSION:
There's no universal solution, but the "standards" way to go is to use the named or numerical entity, not the Symbol font. Sorry, users of Netscape 4.7!

Font forcing Symbol to the Unicode 8593 decimal is a BAD idea. In IE4 it produced an invisible character about 900 pixels wide!
IE 5 & 6 and Netscape 6 & 7 all display nothing for the Symbol font. Not even a blank space, just nothing. Consistent but strange.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Legend of Legaia Demo FAQ page to display a PlayStation directional button.

CONCLUSION:
There's no universal solution, but the "standards" way to go is to use the named or numerical entity, not the Symbol font. Sorry, users of Netscape 4.7!

Font forcing Symbol to the Unicode 8594 decimal is a BAD idea. In IE4 it produced an invisible character about 900 pixels wide!
Netscape 6 and 7 show the "R in a circle" (Registered symbol) for the Symbol font.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Legend of Legaia Demo FAQ page to display a PlayStation directional button.

CONCLUSION:
There's no universal solution, but the "standards" way to go is to use the named or numerical entity, not the Symbol font. Sorry, users of Netscape 4.7!

Font forcing Symbol to the Unicode 8595 decimal is a BAD idea. In IE4 it produced an invisible character about 900 pixels wide!
Netscape 6 and 7 show something like an en dash but very high in the dot matrix, not quite at the top. Whatever it is, it's not what I want.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Legend of Legaia Demo FAQ page to display a PlayStation directional button.

CONCLUSION:
There's no universal solution, but the "standards" way to go is to use the named or numerical entity, not the Symbol font. Sorry, users of Netscape 4.7!

&utri; and &b.Delta; are SGML and probably won't work in HTML.
Font forcing Symbol to the Unicode 9651 decimal isn't helpful. In IE4 it produced a "?".
IE 6 under Windows XP Pro behaves differently than in Windows 2000! The Unicode cases display a box instead of the correct symbol!
Switching to UTF-8 made Netscape 4.7 only marginally better, and it wasn't a useful solution.
The geometric symbol (equilateral triangle) looks more like what I want than the Greek letter (isoceles triangle).

WHERE USED:

• Nowhere on my site but here, actually. I intended to use it on my Legend of Legaia Demo FAQ page to display a PlayStation button, but I created a more representative image to use instead.

CONCLUSION:
There's no universal solution, but the "standards" way to go is to use the named or numerical entity, not the Symbol font. Sorry, users of Netscape 4.7! I avoided this one by creating my own graphic image of the PlayStation button that I was really trying to represent:

&cir; is SGML and probably won't work in HTML.
If all else fails, an acceptable glyph for this is an uppercase letter o, if the font being used isn't script, ornate or decorative. Lowercase is too small for my intended use. The 25EF is a larger version of the 25CB circle symbol.
IE 6 under XP Pro behaves differently than in 2000! The 25EF cases display a box instead of the correct symbol!
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Nowhere on my site but here, actually. I intended to use it on my Legend of Legaia Demo FAQ page to display a PlayStation button, but I created a more representative image to use instead.

CONCLUSION:
Looks like the universal solution for the open circle symbol is the uppercase letter o, font forced to Symbol (Arial comes out too narrow to look like a circle). Sorry everybody! I avoided this one by creating my own graphic image of the PlayStation button that I was really trying to represent:

&squ; is SGML and probably won't work in HTML.
The successful results are actually an assumption. It could be that we're getting the box symbol indicating "browser can't display this", but it looks like an open square. There's no font forcing for this one, as I can't find a square in either Symbol or Arial; the box is definitely a rectangle there in the Windows Character Map.
IE 6 under XP Pro behaves differently than in 2000! The 3 Unicode cases display a noticeably squashed almost-square.
Switching to UTF-8 made Netscape 4.7 significantly better, but it wasn't a universal solution.

WHERE USED:

• Nowhere on my site but here, actually. I intended to use it on my Legend of Legaia Demo FAQ page to display a PlayStation button, but I created a more representative image to use instead.

CONCLUSION:
No universal solution found for the open square symbol. I avoided this one by creating my own graphic image of the PlayStation button that I was really trying to represent:

An acceptable glyph for this is a multiplication sign. Although my intended use is a representation of the X button on the PlayStation, going to the X in a circle symbol in the Symbol font (Alt+0196) was unacceptable since the other 3 buttons would then be missing an enclosing circle. All the non-symbolic fonts that I checked had a multiplication sign at 215, so there's no need for font forcing here. Surprisingly, there was an improvement here for both Netscape 6 to 7 and IE 5 to 6.
Switching to UTF-8 made Netscape 4.7 only marginally better, and it wasn't a useful solution.

WHERE USED:

• Nowhere on my site but here, actually. I intended to use it on my Legend of Legaia Demo FAQ page to display a PlayStation button, but I created a more representative image to use instead.

CONCLUSION:
Use the entity reference for this one. But I stayed consistent and avoided this one too by creating my own graphic image of the PlayStation button that I was really trying to represent:

I'm using a few more symbols too, but these are believed in common enough usage elsewhere that they aren't tested in the exhaustive table form as used above. Or maybe I got lazy.

WHAT & WHERE USED:

• Several of my pages use the copyright symbol © (circled lowercase c, named entity &copy;) in references to material copyrighted by myself or others. Alternate representations for this symbol are the numbered entity &#169; in decimal for ©, &#xA9; in hexadecimal gives you ©, and just "(c)" (although that may not have the same legal binding effect).
• The Greek "male" (or Mars) symbol is part of the name for a particular pokémon on my Pokémon Manual page, the Nidoran male (#29). "♂" (&male;) should do it, but that may be SGML only. Unicode has ♂ or &#x2642; in hexadecimal. This one looks bad on my IE 6 under XP Pro, especially at large Text Size settings.
• The Greek "female" (or Venus) symbol is part of the name for a particular pokémon on my Pokémon Manual page, the Nidoran female (#32). "♀" (&female;) should do it, but that may be SGML only. Unicode has ♀ or &#x2640; in hexadecimal. This one looks bad on my IE 6 under XP Pro, especially at large Text Size settings.
• The mathematical symbol "pi" has a named entity &pi; that looks like π, and Unicode has &#x3c0; in hexadecimal for π, also possibly &#x01d6d1; for 𝛑. The pi symbol is used on my Four Fours FAQ page. While this could be substituted by the Greek lowercase pi, I'm definitely using it in the mathematical sense.
• The fraction "one half" or 1/2 has a named entity &frac12; that looks like ½, and Unicode has &#xbd; in hexadecimal for ½. This fraction is used on my console games page. An alternative representation may be ".5" or "-1/2".

Punctuation Glyph Tests

The following tests are for punctuation glyphs used on this and other web pages on this site. They are all valid for English, and incorrect implementations shouldn't occur.

WHAT & WHERE USED:

• A lot of my pages use the "en dash" for ranges of dates, e.g. 1820–40, or as a connector between related items, e.g. Nazi–Soviet Pact. That's &#x2013; in hexadecimal, according to Unicode. The named entity is &ndash;, which looks like "–". I went to a lot of trouble to put these in, so don't tell me it's the same thing as a "-"! That last was the hyphen, dash, or minus character found near the letter "p" on a standard keyboard, and also on some numeric keypads. Consider that a fallback of last resort.
• Some of my pages use the "em dash" for interruptions, e.g. "No, there's nothing happen—what was that?" That's &#x2014; in hexadecimal, according to Unicode. The named entity is &mdash;, which looks like "—". I went to a lot of trouble to put these in, so don't tell me it's the same thing as a "-"! And that last is the same character used in the previous entry.
• Some of my pages use the horizontal ellipsis, which can be represented with 3 "full stops" in a row ("..."), but it does have it's own symbol, e.g. "Sigh…" that may even render differently. The named entity &hellip; looks like …, or in Unicode … from &#x2026; in hexadecimal.

Language Specifiers

The international standard for specifying language is ISO 639. There are apparently two acceptable versions of this, though. ISO 639 uses two English lowercase letters, and ISO 639-2 uses three English lowercase letters. I don't expect current browsers to understand the 3-letter ones yet. A second group of 2 letters can be appended to the ISO 639 specifier (with a separating "-") to specify a particular dialect or implementation, e.g. "en-US". The second two letters can be uppercase or lowercase, but uppercase seems to be preferred. So, here are some specifiers that I found useful:

• en = English
  • en-US = English, United States
  • en-GB = English, Great Britain
• af = Afrikaans
• ar = Arabic
• zh = Chinese
• nl = Dutch
• fr = French
• de = German
• el = Greek
• he = Hebrew
• hi = Hindi
• it = Italian
• ja = Japanese
• la = Latin
• pl = Polish
• pt = Portuguese
• es = Spanish
• ru = Russian

I've been specifying "en-US" in the headers of my HTML files, then using language specifiers for particular areas of the document with <span xml:lang="xx" lang="xx">blah</span>.

In general, language specifiers don't seem to be helping much with displaying what I want. But at least they don't hurt. So I'll continue to insert them where appropriate.

Overall Evaluation

Unsurprisingly, the current IE 6 and Netscape 7 are best for this set of test cases. The older versions (IE 5.5, 5.0, 4.0 and Netscape 4.7) have various failings. The PC's OS is also a factor, e.g. Windows NT 4.0 had better Unicode support and font renderings than Windows 95b even though both were using IE 4.0. You should use the most recent version of your preferred free web browser software, in the hope that bug fixes and improving standards support will always enhance the experience.

I strongly recommend upgrading any Netscape 4.7 install if at all possible to the most current non-beta Netscape release (8.0.4 as of 2005-10-25), because of the numerous problems fixed compared to 4.7. Or Firefox if you would rather go open-source. I once had a note that said "Netscape (4.7) needs to have user set View/Character Set to UTF-8 to work with the &#bignum; syntax", which is pretty good advice if it helps even a little and doesn't hurt.

The PRE construct was a fluke that I discovered, but I can't see a good use for it. The <PRE> construct only displays the desired character if you don't set font-family: monospace for PRE using CSS; but at least one CSS expert recommends that you do. If you do, you get useless boxes instead. Therefore, this little fluke in the browsers is even less useful than previously believed.

MATH tags seemed to only cause validator errors, and not render as anything different.

Declaring the language didn't seem to help at all.

What's New

Site Navigation

Counter says: hits on this page since initialization.
By Peter Karsanow.
The Home page has overall site and copyright information.