That is all good feedback.
We had a bit different design center, which was to have glyphs that were
recognizable primarily for users of the script. While the symbols could
also be looked up in a simple chart for non-users, we felt that if you
didn't know what the character was, it probably was of little concern.
About kana: originally we had a simpler list of glyphs, but ended up
adding a separate glyph for each Unicode block for consistency. While it
is unlikely that fonts will be constructed based solely on block
boundaries, that does provide a bit finer distinction.
By the way, the document that Mark L. mentions was a proposal, not a
final document. The UTC decided on a few changes beyond what is there:
one was to design the font to have widths more consistent with the
average for the block.
Moreover, more sophisticated systems could also augment the font by
having such features as:
- hex digits for each character.
- "fly-over" boxes with more information.
Unicode Discussion wrote:
> One other issue regarding usability in the LastResort font. Several
> months ago, I asked why the "ka" glyph (U+AC00, in a rounded rectangle,
> of course) was being proposed as a representative of Hangul. I asked if
> it wouldn't be better if the "han" (U+D55C) in "hangul" were used
> instead. "Han" would *mean* "hangul" to a Korean speaker, but "ka" would
> just *be* hangul. Apparently, it was decided to go ahead and use the
> "ka" anyway.
> In the case of Devanagari and Bengali, I can't read either language, and
> distinguishing between those two glyphs is pretty tough for me. If I
> ever had to work with them, it would be quite a challenge to avoid
> making a mistake. "Dev" and "Ben" (or something similar in the Latin
> alphabet) would be a lot easier for me to distinguish and
> remember--thus, a lot less error prone.
> In the cases of Japanese and Korean, though, I have the opposite
> usability problem. I've been a speaker of both since I was a teenager
> (almost 20 years), and a professional translator of both at various
> times, and when I see the LastResort glyphs for hangul and kana, I don't
> see a *script*, I see a "ka". The glyphs for hangul, katakana, and
> hiragana are all characters for "ka". Although there is less aspiration
> in the Korean "ka", a mixed string of hangul, hiragana, and katakana in
> the LastResort font looks to me like:
> Ironically, it might still be easier for me to distinguish "Hgl" from
> "Ktk" from "Hrg", in this case because I *can* read these scripts, not
> because I can't. I think the character version would be easier than the
> latin version (for me) if they didn't all instantly become "ka" in my
> mind when I glanced at them.
> This is just my personal feeling regarding usability, and I'm sure there
> are a lot of other issues to consider, as well as a lot of other
> opinions. I really like the idea of a LastResort font, and I'm grateful
> for it and for those who are doing so much work on it. It would just be
> a little easier for me personally, as a user, if there were
> 1) a version of the font that used latin abbreviations to make it easier
> for me to identify and distinguish scripts I couldn't read, as well as
> making technical distinctions such as "CJK compatibility", and
> 2) for scripts that I could read, if the glyphs in the character version
> were chosen so as to clearly announce to me what scripts they
> represented. If the hangul glyph shouted "han" in hangul, the katakana
> glyph said "ka" ("kata" would be better if not too big) in katakana, and
> the hiragana glyph said "hi" (or "hira") in hiragana, they would
> identify themselves at two levels. I wouldn't have to tell myself, "no,
> slow down, don't *read* it, just look at the glyph: which *script* is
> it?" I could just glance at it, and it would identify itself without
> additional conscious effort.
> __Glen Perkins__
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:35 EDT