🚀 go-pugleaf

An interesting OS/2 problem involving the items in the subject line has
just landed in my lap. The description is quite lengthy, as the problem
seems fairly intricate, but of fundamental importance for the future of
multilingual text processing within OS/2. At the bottom I ask for
advice from more experienced users.

I have installed a few dozen genuine Adobe fonts for OS/2 (the entire
Minion family, including Minion Cyrillic, which maps Cyrillic characters
into the upper cells). These do not work properly either in DeScribe
(native OS/2 version) or the OS/2 Enhanced Editor. I have also installed
them in Win-OS/2 and they work fine in AmiPro for Windows (they also
work in genuine Windows 3.1). DeScribe technical support explained what
was going on, and it ain't pretty. I tossed around some ideas with
them, but I'd be grateful for suggestions from users who have met and
conquered this problem already. The gist was that the character set
handling problems arise within OS/2 and DeScribe could only avoid them
by bypassing the operating system, which clearly isn't what is supposed
to happen with a competent operating system.

Specifically, OS/2 expects to see two code pages, which are specified in
the config.sys file. One of these is CP 850, which is ASCII in the lower
128 cells and a particular inventory and arrangement of characters in
the upper 128 cells. The Minion fonts, including the Latin-alphabet
ones, do not correspond to CP 850 either in inventory or in
arrangement. (Since they do not correspond in inventory, there is
obviously no way that they could possibly correspond in arrangement.)

DeScribe sees all my installed fonts and lists them as available. As
long as I restrict myself to characters from the lower 128 cells,
everything is fine. (Well, not everything, but that's a story for
another posting; the other problems are not relevant to the one
described here.) But if I try to use characters from the upper 128
cells, I don't get what I expect. For example, I load Minion Regular,
which has <o+diaeresis> in a particular upper cell, and enter this
number from the numeric keypad. What appears on my screen is a division
sign, which is what lives in this cell in CP 850. Not only is there no
division sign in this cell in my selected font, but there is no
division sign anywhere in my selected font, and OS/2 has fetched one
from somewhere else for me. A random stroll through the upper 128 cells
revealed that entering most of these values from the numeric keypad
simply produces a blob on the screen, while others produce the wrong
characters, including characters that are not even part of the font.

DeScribe technical support explained that OS/2 is designed to use CP 850
(or whatever gets specified in the config.sys file) and remaps or
substitutes characters that _it doesn't think_ are correct. It
apparently checks the character name (either in the .afm or .pfb file)
and if it doesn't match the CP 850 character that should be in the
selected cell it refuses to display it!

As a common, vexing, but not irremedial problem that results from this
OS/2 limitation, DeScribe does not currently include typographic
(curly) quotes simply because there are no typographic quotes in CP
850. The fix is to write a macro that will switch fonts to one with
typographic quotes, plug 'em in, and then switch back. Not very pretty,
and not something easily applied to larger problems, such as entire
"foreign" alphabets.

The general fix for more comprehensive problems, such as getting at the
Cyrillic characters in Minion Cyrillic, is to use Fontographer to
rewrite the font file and designate its character set type as "Symbol"
(rather than "ANSI," which is Fontographer's preference). DeScribe
explains that if a font is tagged as "Symbol," OS/2 ignores the
character name and simply fetches what's in the cell. I have tried this
and it works, but with one obvious problem and perhaps some subtle ones:

Obvious problem: Fontographer doesn't generate fonts as good as those
you can buy from Adobe. If you rewrite the font, you lose quality.

Subtle problems: I haven't had a chance to check whether there are other
consequences of changing the character set type information for a font.
One possibility is that I would lose automatic case conversion. Another
is that case-insensitive searching would fail. Another may be an
inability to sort other than by strict machine order (DeScribe supports
various alternative sort orders). I don't expect easy handling of
Cyrillic alphabet characters from the upper reaches of my fonts, but I
don't want to sacrifice the alphabetic properties of the
ASCII-compatible lower 128 cells.

Possible solution to obvious problem: change the character type
designation in the .pfb and/or .afm files without actually rewriting
the .pfb file through Fontographer. I've picked up some hints on how
this might be done (thanks, Kamal), but if anyone has actually done
this or knows _exactly_ what lines to change and _exactly_ what to
change them to, I'd be grateful for the advice. The .afm files are
already text, and the t1 utilities will convert from .pfb to .pfa (an
ASCII text equivalent of the .pfb) without loss of information, so the
problem isn't making the changes, but knowing what to change.

Meanwhile, I installed OS/2 and Win-OS/2 fonts to the same directory,
since they normally share .pfb files. If I'm going to dicker with the
pfb files, is it going to lead to problems in Win-OS/2? If so, I can
always install the fonts separately for OS/2 and Win-OS/2 and fiddle
only with the latter, but I'd prefer not to do that (it wastes disk
space) if there are changes I can make that will fix OS/2 without
breaking Win-OS/2.

<editorial mode>From a broader perspective, what type of design
decision is this (a euphemism for "what the hell type of design
decision is this?")? If the selected font doesn't match CP 850 in
either layout or inventory, either the user made a mistake or the user
actually needs characters that are not available in CP 850 but are
available in the font the user has selected. Just as OS/2 doesn't try
to "protect" me from typographical errors, it should not try to protect
me from selecting characters that are obviously available in my font.
OS/2 might not be able to support characters that are not part of CP
850 fully (e.g., it might not provide alphabetic operations, such as
case conversion, on characters outside the defined code pages), but it
should be able to display them.</editorial mode>

To return to the original problem: what should an OS/2 user with
multilingual requirements that are not satisfied within CP 850 do now?
Please note that I deliberately did not post this in an advocacy group;
assume for this exercise that switching machines or operating systems
is not an available option.

Please email and I will summarize to the groups where this message was
originally posted. Thanks,

David
--
Professor David J. Birnbaum         djbpitt+@pitt.edu [Internet]
The Royal York Apartments, #802     djbpitt@pittvms   [Bitnet]
3955 Bigelow Boulevard              voice: 1-412-687-4653
Pittsburgh, PA  15213  USA          fax:   1-412-624-9714