Hmm, you could theoretically assign chars in the private unicode area to
the chars you need -- but then have your application replace those chars
by small images on rendering/display.
This seems as clean a solution as you are likely to find. Your TEI
solution still requires chars-as-images for these unusual chars, right?
So this is no better with regard to copying-and-pasting, browser
display, and general interoperability than your TEI solution, but no
worse either -- it's pretty much the same thing. But it may be better in
terms of those considerations for chars that actually ARE currently
unicode codepoints.
If any of your "private" chars later become non-private unicode
codepoints, you could always globally replace your private codepoints
with the new standard ones.
With 137K "private codepoints" available, you _probably_ wouldn't run
out. I think. You could try standardizing these "private" codepoints
among people in similar contexts/communities to you and your needs -- it
looks like there are several existing efforts to document shared uses of
"private codepoints" for chars that do not have official unicode
codepoints. They are mentioned in the wikipedia article.
[Reading that wikipedia article taught me something new I didn't know
about Marc21 and unicode too -- a topic generally on top of my pile
these days -- "The MARC 21 standard uses the [Private Use Area] to
encode East Asian characters present in MARC-8 that have no Unicode
encoding." Who knew? ]
Jonathan
Jakob Voss wrote:
Hi Stuart,
These have been included because they are in widespread use in a current
written culture. The problems I personally have are down to characters
used by a single publisher in a handful of books more than a hundred
years ago. Such characters are explicitly excluded from Unicode.
In the early period of the standardisation of the Māori language there
were several competing ideas of what to use as a character set. One of
those included a 'wh' ligature as a character. Several works were
printed using this ligature. This ligature does not qualify for
inclusion in Unicode.
That is a matter of discussion. If you do not call it 'ligature' chances
are higher to get it included.
To see how we handle the text, see:
http://www.nzetc.org/tm/scholarly/tei-Auc1911NgaM-t1-body-d4.html
The underlying representation is TEI/XML, which has a mechanism to
handle such glyphs. The things I'm still unhappy with are:
* getting reasonable results when users cut-n-paste the text/image HTML
combination to some other application
* some browsers still like line-breaking on images in the middle of words
That's interesting and reminds me on the treatment of mathematical
formula in journal titels which mostly end up as ugly images.
In Unicode you are allowed to assign private characters
http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Private_use_characters
The U+200D ZERO WIDTH JOINER could also be used but most browsers will
not support it - you need a font that supports your character anyway.
http://blogs.msdn.com/michkap/archive/2006/02/15/532394.aspx
In summary: Unicode is just a subset of all characters which have been
used for written communication and whether a character gets included
depends not only on objective properties but on lobbying and other
circumstances. The deeper you dig the more nasty Unicode gets - as all
complex formats and standards.
Cheers
Jakob
P.S: Michael Kaplan's blog also contains a funny article about emoji:
http://blogs.msdn.com/michkap/archive/2010/04/27/10002948.aspx
