𐐜 𐐔𐐇𐐞𐐊𐐡𐐇𐐓 𐐈𐐢𐐙𐐊𐐒𐐇𐐓

𐐔𐐯𐑆𐐲𐑉𐐯𐐻 𐐮𐑆 𐐩 𐑁𐐬𐑌𐐯𐐻𐐮𐐿 𐐰𐑊𐑁𐐲𐐺𐐯𐐻 𐐷𐐭𐑆𐐼 𐐻𐐭 𐑉𐐴𐐻 𐐊𐑋𐐯𐑉𐐲𐐿𐐲𐑌 𐐀𐑍𐑊𐐮𐑇. 𐐜 𐑅𐐿𐑉𐐮𐐹𐐻 𐐶𐐲𐑆 𐐼𐐨𐑂𐐯𐑊𐐲𐐹𐐻 𐐮𐑌 𐑄 𐑋𐐮𐐼𐑊 𐐹𐐪𐑉𐐻 𐐲𐑂 𐑄 𐐩𐐻𐐨𐑌𐑃 𐑅𐐮𐑌𐐽𐐲𐑉𐐨 𐐺𐐴 𐑄 𐐒𐐬𐑉𐐼 𐐲𐑂 𐐡𐐨𐐾𐐲𐑌𐐻𐑅 𐐲𐑂 𐑄 𐐏𐐭𐑌𐐮𐑂𐑉𐑅𐐮𐐻𐐨 𐐲𐑂 𐐔𐐯𐑆𐐲𐑉𐐯𐐻 𐐲𐑌𐐼𐑉 𐑄 𐐼𐐴𐑉𐐯𐐿𐑇𐐲𐑌 𐐲𐑂 𐐒𐑉𐐮𐑀𐐲𐑋 𐐏𐐲𐑍.

𐐊𐑊𐐱𐑍 𐐶𐐮𐑄 𐐰𐑌 𐐲𐑌𐐼𐑉𐑅𐐻𐐰𐑌𐐼𐐲𐐺𐑊 𐑅𐐿𐐬𐑉𐑌 𐑁𐐬𐑉 𐑄 𐐯𐑉𐐰𐐻𐐮𐐿 𐑂𐐩𐑀𐐪𐑉𐐨𐑆 𐐲𐑂 𐐀𐑍𐑊𐐮𐑇 𐑅𐐹𐐯𐑊𐐨𐑍, 𐐒𐑉𐐮𐑀𐐲𐑋 𐐏𐐲𐑍 𐑉𐐨𐐹𐐬𐑉𐐻𐐯𐐼𐑊𐐨 𐑁𐐯𐑊𐐻 𐑄𐐰𐐻 𐐸𐐰𐑂𐐨𐑍 𐐩 𐑁𐐬𐑌𐐯𐐻𐐮𐐿 𐑅𐐿𐑉𐐮𐐹𐐻 𐑁𐐬𐑉 𐐀𐑍𐑊𐐮𐑇 𐐶𐐳𐐼 𐑋𐐩𐐿 𐐮𐐻 𐐨𐑆𐐨𐐯𐑉 𐑁𐐬𐑉 𐑉𐐨𐑅𐐲𐑌𐐻 𐐏𐐭𐑉𐐬𐐹𐐨𐐯𐑌 𐐮𐑋𐐮𐑀𐑉𐐲𐑌𐐻𐑅 (𐐿𐐲𐑌𐑂𐑉𐐻𐐨𐑍 𐐻𐐭 𐑄 𐐕𐑉𐐽 𐐲𐑂 𐐖𐐨𐑆𐐲𐑅 𐐗𐑉𐐴𐑅𐐻 𐐲𐑂 𐐢𐐰𐐻𐑉 𐐔𐐩 𐐝𐐩𐑌𐐻𐑅) 𐐻𐐭 𐑊𐑉𐑌 𐐀𐑍𐑊𐐮𐑇.

𐐝𐐯𐑂𐑉𐐲𐑊 𐐺𐐳𐐿𐑅 𐐶𐑉 𐐹𐑉𐐮𐑌𐐻𐐮𐐼 𐐮𐑌 𐑄 𐑅𐐿𐑉𐐮𐐹𐐻, 𐐮𐑌𐐿𐑊𐐭𐐼𐐨𐑍 𐑄 𐐒𐐳𐐿 𐐲𐑂 𐐣𐐬𐑉𐑋𐐱𐑌 𐐰𐑌𐐼 𐑅𐐲𐑋 𐐹𐑉𐐴𐑋𐐰𐑉𐐨 𐑉𐐨𐐼𐑉𐑆 𐑁𐐬𐑉 𐑅𐐿𐐭𐑊 𐐽𐐮𐑊𐐼𐑉𐐲𐑌, 𐐺𐐲𐐻 𐑄 𐐲𐑌𐐼𐑉𐐻𐐩𐐿𐐨𐑍 𐐹𐑉𐐭𐑂𐐼 𐐻𐐭 𐐺𐐨 𐐿𐐱𐑅𐐻-𐐹𐑉𐐬𐐸𐐮𐐺𐐮𐐻𐐮𐑂.

𐐈𐑁𐐻𐑉 𐐒𐑉𐐮𐑀𐐲𐑋 𐐏𐐲𐑍'𐑅 𐐼𐐯𐑃 (1877) 𐑄 𐐕𐑉𐐽 𐐼𐐮𐐼 𐑌𐐱𐐻 𐐹𐑉𐑅𐐭 𐑄 𐐹𐑉𐐪𐐾𐐯𐐿𐐻.

𐐟𐐳𐐼 𐐷𐐭 𐐺𐐨 𐑁𐐬𐑉𐐽𐐭𐑌𐐲𐐻 𐐨𐑌𐐲𐑁 𐐻𐐭 𐐬𐑌 𐐶𐐲𐑌 𐐲𐑂 𐑄 𐐬𐑉𐐮𐐾𐐲𐑌𐐲𐑊 𐐿𐐪𐐹𐐨𐑆 𐐲𐑂 𐑄𐐨𐑆 𐐺𐐳𐐿𐑅 𐐹𐐲𐐺𐑊𐐮𐑇𐐻 𐐮𐑌 𐐔𐐯𐑆𐐲𐑉𐐯𐐻, 𐐷𐐭 𐑇𐐳𐐼 𐑌𐐬 𐑄𐐰𐐻 𐑅𐐲𐐽 𐐺𐐳𐐿𐑅 𐐪𐑉 𐐿𐐶𐐴𐐻 𐑉𐐩𐑉 𐐰𐑌𐐼 𐐷𐐭 𐑇𐐳𐐼 𐐸𐐰𐑂 𐐮𐐻 𐐰𐐹𐐹𐑉𐐩𐑆𐐼 𐐺𐐴 𐐩 𐑉𐐯𐐹𐐷𐐭𐐻𐐲𐐺𐑊 𐑉𐐩𐑉 𐐺𐐳𐐿 𐐼𐐨𐑊𐑉.

Deseret is now officially encoded in the Secondary Multilingual Plane, also called Plane One.

There may still be problems displaying the text on some systems which support non-BMP ranges of Unicode. In order to avoid having the browser ignore the spacing character (it was running some words together) it was necessary to add a couple of line feeds between each word in the source HTML.

Also, had to manually set the view/encoding to “User Defined” after selecting the desired Plane One font as the “User Defined” font in the [Tools] - [Internet Options] - [General] - [Fonts] menu. This is because, in order to be able to claim that this page is valid HTML and add the valid HTML graphic from W3 to this page, the character set (charset) declaration in the HTML header was changed from “x-user-defined” to “UTF-8”.

Using the user defined charset would force this page to load correctly the first time in the Internet Explorer browser, as long as an appropriate font was selected for the user defined font setting in the tools-internet options menu. But “x-user-defined” is apparently a Windows-specific internal code page, and the W3C validator is quite correct in rejecting it as an invalid charset.

Using the UTF-8 charset tag forces the Internet Explorer browser to load this page as UTF-8, using some internal font selection mechanism which is somewhat vague and unpredictable. Unless the font is specified in the HTML header, the browser may select a font which doesn't include any glyphs in the desired range over a font which has the glyphs.

In order for a user to display pages encoded using NCRs but labelled as charset UTF-8 correctly, the user has to manually switch the encoding to user defined in the [View] - [Encoding] menu. Not just once, but each and every time the page is visited or even just refreshed. This means the user is forced to load the page twice, and with some servers, this means running banners, pop-up screens, cookies, and other scripted nonsense twice, too.

One solution would be to simply select appropriate fonts using a STYLE declaration. But, that would make this a “font-specific” page, and since the purpose of these pages is to allow people to test their own browsers and fonts on various scripts of Unicode, making this page font-specific would defeat one of its purposes. (This solution won't work as of this writing anyway, UTF-8 Plane One text can't be displayed in the browser regardless of whether real UTF-8 or NCRs are used. My understanding is that the various browser programmers are working on the Plane One UTF-8 bug, and this could well be fixed soon, if not already.)

Font-specific pages have problems of their own. Many web pages are now setting the new Unicode version of Arial as their preferred font for multilingual text. Those of us who don't have the new version of Arial installed, mainly because of license restrictions, usually have an older version of the Arial font installed because Arial has been popular for a long time. This means that when looking at, for instance, the otherwise wonderful Universal Declaration of Human Rights font-specific multilingual pages at the United Nations' web site, many of the pages display with a lot of “missing glyph” or null-boxes. In order to correctly display the page under those conditions, the user must save a copy of the HTML file to disk, open the HTML file in an editor, manually change the style or font-face declaration to a more appropriate selection, and then load the altered, archived HTML file back into the browser while off-line.

So, the other alternative for correct display is to simply set the charset to x-user-defined. This is what was done on my Gothic Plane One test page at http://home.att.net/~jameskass/gothictest.htm, and this is a popular method with web page authors. It may not be valid-HTML, but it works.

My home page