Taanshi, <br><br>I am wondering how to go about creating a new character and how to go about getting a unicode codepoint for it.  What I have in mind is is an <n> with a</> over it....  Any advice or suggestions?<br>
<br>Kihchi-maarsii!<br><br>Eekoshi.<br>Heather Souter<br>Michif Language Activist and<br>Community Linguist<br><br><div class="gmail_quote">On Fri, May 16, 2008 at 5:04 PM, William J Poser <<a href="mailto:wjposer@ldc.upenn.edu">wjposer@ldc.upenn.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Keola Donaghy 'uk'uneisguz:<br>
<div class="Ih2E3d"><br>
>Aloha We created and used our custom fonts back in 1994 and are<br>
>still slowly trying to wean ourselves from them and switch<br>
>completely to Unicode.<br>
<br>
</div>Actually, I think this confirms what I have been saying: using<br>
custom fonts is NOT a problem, except in cases like cell phones<br>
and work machines over which users have no control, where you<br>
can't install them.<br>
<br>
The problem is not custom fonts, it is custom ENCODINGS.<br>
<br>
Since I think some people may not be clear on the distinction,<br>
let me explain. Text in a computer really consists of a sequence<br>
of character codes, which are non-negative integers. The computer<br>
doesn't really store an "a" - it stores a number which by convention<br>
is associated with the character "a". Once upon a time, in the days<br>
of "dumb terminals" and fixed-encoding keyboards, this was all hard-wired.<br>
When you pressed the "a" key on your keyboard it sent a certain small<br>
integer to your computer, and when the computer sent that same small<br>
integer to the terminal, the terminal displayed the corresponding<br>
glyph. Nowadays it is possible to program what codes are generated by<br>
particular keyboard events and what glyphs are displayed, but<br>
the basic principle is the same: text consists of a sequence of<br>
numbers.<br>
<br>
What until recently was by far the most common encoding was ASCII,<br>
in which "a" has the character code 97. (Character codes are normally<br>
given in hexadecimal but I'll translate into decimal here.) "b" is<br>
98, "c" is 99. "A" is 65, "B" is 66, "C" is 67, etc. So, if you<br>
have an ASCII-encoded font containing glyphs for the roman alphabet,<br>
sending the code 98 to the display will select the glyph for "b"<br>
and display it.<br>
<br>
For other languages there are other encodings. If, for example,<br>
you use the ARMSCII7 encoding (which you might have done if you<br>
were an Armenian), if you send the code 98 to the display instead<br>
of the letter "b" you would get the Armenian capital letter cha.<br>
<br>
Until recently, at best there was a single standard for each language<br>
and writing system, so that everybody would be on the same wavelength<br>
within that language and writing system. Fonts for Armenian or<br>
Russian or Hebrew or whatever would be encoded according to the<br>
standard for that language. Then things would be simple so long<br>
as you were using that language, but would get messy if, say,<br>
you need to use Armenian and English in the same document, or<br>
wanted to write in Russian on a machine set up for Hebrew.<br>
Furthermore, in many cases there were multiple encodings for the<br>
same writing system. Sometimes, every font had its own idiosyncratic<br>
encoding. (The champions seem to be the Ethiopians, who had over<br>
40 known encodings for Amharic.)<br>
<br>
In this situation, where every font potentially uses its own<br>
encoding, for other people to use your font it isn't sufficient<br>
for them to install it - their software has to understand its<br>
encoding.<br>
<br>
With much current software, so long as your font uses a well-known<br>
encoding, the software can use it because it contains or knows how<br>
to look up information about the encoding. Your browser, for example,<br>
almost certainly (a) attempts to detect the encoding of the web page<br>
it displays and (b) allows you to tell it what encoding to use (in case<br>
it fails to guess correctly - this happens with some frequency, in part<br>
because many web pages lie about their encoding and the browser accepts<br>
the lie). But if you have a truly idiosyncratic encoding in your font,<br>
software may not know what to do with it.<br>
<br>
What Unicode does is unify all writing systems into a single encoding.<br>
In Unicode "b" and Armenian capital cha do not compete for the<br>
same codepoint. Instead, "b" is 98 as in ASCII and Armenian capital<br>
cha is 1353. With everything included in a single encoding, you can<br>
mix writing systems easiy within a single document and use one writing<br>
system on a system set up for another.<br>
<br>
So, if you create your own font but use Unicode as the encoding,<br>
so long as people are able to install your font they should have no<br>
problem using it. What you should not do is create fonts that use<br>
your own idiosyncratic encoding.<br>
<br>
One of the uses of FontForge is in fact reencoding an existing font.<br>
You can see an example of this at:<br>
<a href="http://billposer.org/Linguistics/Computation/Reencoding/HowTo.html" target="_blank">http://billposer.org/Linguistics/Computation/Reencoding/HowTo.html</a><br>
The examples used in this tutorial are based on a real task.<br>
I wanted to be able to use Linear B and at the time could only<br>
find a font that used an idiosyncratic encoding. So I took that<br>
font and changed the encoding to Unicode.<br>
<br>
Bill<br>
</blockquote></div><br>