Re: Xpl accident

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Patricia M. Godfrey"  on Sat, 01
Apr 2006 15:57:19 -0500

It's a freak accident. What are your KBD assignments? To generate real
guillemets, KBD should be assigned 3-byte guillemets; to generate 3-byte
guillemets, KBD should have 5-byte guillemets *preceded by a function* like NI
or NO.

Real 1-byte guillemets:
 51={255-65-69} <==both of these *look* like
 52={255-65-70} <==ordinary guillemets

3-byte pseudo-guillemets:
 51=NI{255-70-70},A,E <==*Note* there is NO SPACE between
 52=NI{255-70-70},A,F <==func NI and the 3-byte 255|FFh
The above will *look* like:
 51=NI ,A,E
but that "space" is really a 3-byte 255.

You can write any of those 3-byters with frame PUTCHAR, e.g.
 putchar 174d,3
which is the same as
 putchar AEh,3
You can also write them with frame MAKE3BYTER, e.g.
 m3 255-65-69
All of the above examples generate a 3-byte left guillemet.

The principle here (at risk of repeating what is known to all) is that 3-byters
in the KBD file are transformed into 1-byters when the keystroke is "put" to
text. Hence the need for 5-byters in the KBD to get 3-byters in text: a
3-byte 255 plus "AE" generates a 1-byte 255+"AE", which = a 3-byte left
guillemet.

When you're done -- Important! -- *verify* that the results are the correct
characters by putting your cursor on top of them individually and commanding
 V3

The ornamental 3-byters are great for documentation, as long as the docs will
be read in XyWrite (outside XyWrite they're garbage). They look just like
guillemets, but aren't -- they're passive nothings.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------