Keying Popular Orthographies in MS Word

[Koontz John E]

On Thu, 3 May 2001, Language wrote:
> We originally started out using the SIL fonts and they worked quite
> well originally until we changed them to Arial or Times New Roman,
> they just came out as squares but this was ten years ago and the SIL
> fonts are compatible with Microsoft now.  The "Insert
> menu-Symbols-normal text" method allows you to assign symbols to the
> keyboard as well.  However none of these work yet with e-mail
> programs.

I'm not sure I followed the first part.  I've used the SIL font generating
tools for years - both editions of the HP printer fonts only for DOS
(Premier and Legacy Fonts) and the first version for TrueType fonts for
Windows (Encore Fonts).  I believe there's a major update of Encore Fonts
that I haven't used.  They always worked for me but have never included
tools for creating Arial or New Times fonts.  Premier Fonts used Bitstream
faces called Dutch and Swiss (Bitstream versions of Times and Helvetica),
plus some others.  Legacy Fonts and Encore Fonts use SIL creations called
Doulos and Sophia (plus Manuscript, a non-proportional font).  I think
they claim that Doulos or more or less Times-like, but Sophia is not
Helvetica-based.  I forget what they say it is like - maybe Futura?  The
SIL faces look rather blobby in Windows but generally print acceptably.

It's true that anything encoded for use in the DOS ASCII environment
couldn't simply be ported to the Windows ANSI environment in most cases.
The problem is that the upper range (128-255) is defined differently in
the two environments and Windows, especially Word for Windows, has some
conventions regarding the upper range that can be awkward. Things coming
out as squares sounds like a mapping problem between DOS ASCII-based fonts
and Windows ANSI-based fonts.

You're quite right that the insert Symbols menu has a facility for
defining keyboard shortcuts.  I had never noticed this!  Unfortunately it
doesn't allow assigning multicharacter and/or styled text to shortcuts, so
you can't generate a<superscript n>, or even <superscript n>. There is
also an entry to the autocorrect facility here, but it looks like this
version can't pick up multi-character highlighted sequences.

As near as I can tell by experimenting, defining aN to be autocorrected to
a<super n> causes AN, An, and aN to be mapped to a<super n>, with only an
escaping unscathed.  If you don't turn off automatic capitalization at the
start of a sentence, some of the a's will be A's.  I have no idea why An
is treated with AN and aN.  It does appear that the autocorrecting
facility ignores case in the input, which explains a lot.  But then why is
an safe?