mnu@gibbon.inel.gov (Rick Morneau) (08/30/90)
I am currently working on a PostScript Hiragana font for use with the
WriteNow word processor on my NeXT computer. The current version is a
simple state machine that reads one, two or three roomaji letters and
draws a single kana symbol. Since there is no one-to-one mapping
between a key and a kana symbol, the PostScript interpreter cannot
save the bitmaps for each kana for subsequent re-use. Instead,
it must redraw the symbol each time, which considerably slows down
both display and printing.
Anyway, it occurred to me that I might be better off if I designed
the font so that a single key would correspond to a single kana. The
question is, which keys should correspond to which kanas? Obviously,
the stand-alone vowels are easy to map. But what do I do about the
consonant-vowel syllables? I.e., which key should I use for "SA", which
key for "NU", etc. In other words, is there a standard or conventional
mapping between Japanese kana and English keyboards?
If anyone out there knows the answer to this question, I would really
appreciate hearing from you. Since I am going to do this, I want to
do it right.
BTW, I'm designing the font in my spare time, and if time permits,
I will also do fonts for Katakana and Kanji. They are simple stroked
characters, and cannot compete with professionally done fonts (I do
not have the artistic talent or patience needed to do a professional
job). But I WILL make them available to anyone who is interested (just
don't hold your breath :-).
To respond by email, please do not use the address shown in the
header. Instead, please use the address:
mnu@nairobi.inel.gov
Thanks in advance!
BTW, I am not responsible for the disclaimer that follows.
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
= Rick Morneau Idaho National Engineering Laboratory =
* mnu@nairobi.inel.gov Idaho Falls, Idaho 83401 *
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neither the United States Government nor the Idaho National
Engineering Laboratory nor any of their employees, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility
for the accuracy, completeness, or usefulness of any information,
product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific
commercial products, process, or service by trade name, trademark
manufacturer, or otherwise, does not necessarily constitute or imply
its endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory. The views and
opinions of authors expressed herein do not necessarily state or reflect
those of the United States Government nor the Idaho National Engineering
Laboratory, and shall not be used for advertising or product endorsement
purposes.glenn@heaven.woodside.ca.us (Glenn Reid) (09/01/90)
In article <1990Aug29.205350.27338@inel.gov> mnu@gibbon.inel.gov (Rick Morneau) writes: >I am currently working on a PostScript Hiragana font for use with the >WriteNow word processor on my NeXT computer. The current version is a >simple state machine that reads one, two or three roomaji letters and >draws a single kana symbol. Since there is no one-to-one mapping >between a key and a kana symbol, the PostScript interpreter cannot >save the bitmaps for each kana for subsequent re-use. Instead, >it must redraw the symbol each time, which considerably slows down >both display and printing. > >Anyway, it occurred to me that I might be better off if I designed >the font so that a single key would correspond to a single kana. You can do both, I think. I don't know that much about Japanese, I must confess, but here's what you might consider doing at the font level: If I understand what you have done so far, you have made a PostScript font that itself maintains a state machine and doesn't image a character until it has queued up some number of key strokes, and that you can't use the font cache because you don't know what sequence will trigger the kana bitmap. You might be able to solve this problem by creating two fonts. One font would be a set of kana symbols with some unique ASCII value for each character. The other font would be the one you have now, a "state machine" font. The state machine font could, inside the BuildChar procedure, invoke the other font along the lines of: /BuildChar { % figure out which kana character you need /KanaFont findfont 1000 scalefont setfont (c) show % c is code for kana character } def I think that might do the trick, and the "KanaFont" could use the font cache to store the bitmaps. I think there's an example in the green book somewhere that uses a font within a font, if you need some guidelines on how to do this. /Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785