Xref: utzoo comp.fonts:1449 comp.lang.postscript:6010
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.fonts,comp.lang.postscript
Subject: Re: How do I map a Hiragana font to an English keyboard?
Keywords: Hiragana Font Keyboard Mapping
Message-ID: <264@heaven.woodside.ca.us>
Date: 1 Sep 90 00:39:41 GMT
References: <1990Aug29.205350.27338@inel.gov>
Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid)
Followup-To: comp.fonts
Organization: RightBrain Software, Woodside, CA
Lines: 46

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