Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.mathworks.com!zombie.ncsc.mil!newsgate.duke.edu!news-feed-1.peachnet.edu!paperboy.wellfleet.com!news3.near.net!amber.ora.com!not-for-mail
From:
[email protected] (Norman Walsh)
Newsgroups: comp.fonts,comp.answers,news.answers
Subject: comp.fonts FAQ: OS/2 Info
Supersedes: <
[email protected]>
Followup-To: poster
Date: 14 Aug 1996 10:34:55 -0400
Organization: O'Reilly and Associates, Inc.
Lines: 397
Sender:
[email protected]
Approved:
[email protected]
Distribution: world
Expires: 27 Sep 1996 14:34:08 GMT
Message-ID: <
[email protected]>
References: <
[email protected]>
Reply-To:
[email protected] (Norman Walsh)
NNTP-Posting-Host: ruby.ora.com
Summary: This posting answers frequently asked questions about fonts.
It addresses both general font questions and questions that
are specific to a particular platform.
X-Web-Homepage:
http://www.ora.com/homepages/comp.fonts/
Xref: senator-bedfellow.mit.edu comp.fonts:48305 comp.answers:20519 news.answers:79240
Archive-name: fonts-faq/part9
Version: 2.1.5
Subject: 4. OS/2 Information
[ed: Except as otherwise noted, the entire OS/2 section of the
comp.fonts FAQ List is derived from the "Draft OS/2 Font FAQ" posted by
David J. Birnbaum.]
This section if the FAQ is Copyright (C) 1993 by David J. Birnbaum.
All Rights Reserved. Reproduced here by permission.
[ed: Since this section of the FAQ is wholly derived from David's
document, some sections contain information repeated elsewhere in the
comp.fonts FAQ.]
David Birnbaum's Introduction
=============================
4 June 1993
A couple of weeks ago I posted an inquiry to comp.fonts,
comp.os.os2.misc, and the OS2-L ListServ concerning some apparent
peculiarities in the way OS/2 handles font files. These "peculiarities"
actually reflect regular, systematic differences in OS/2, Windows, and
DOS font handling, which are not conveniently described in end-user
documentation. This posting is intended to spare others some of the
confusion I encountered as a result of this paradigm shift.
This is the first (draft) distribution of this document and corrections
and suggestions are welcome. I am grateful to Henry Churchyard, Marc L.
Cohen, Bur Davis and Kamal Mansour for helpful discussions; they are
not, of course, responsible for any misinterpretation I may have
inflicted on their comments.
Subject: 4.1. Preliminaries
Character: an informational unit consisting of a value (usually a byte)
and roughly corresponding to what we think of as letters, numbers,
punctuation, etc.
Glyph: a presentational unit corresponding roughly to what we think of
as letters, numbers, punctuation, etc.
Character vs glyph: Glyph and character are not necessarily the same;
the character <a> may be mapped to a Times Roman Lower Case <a> glyph
in one font and to a Helvetica Lower Case <a> glyph in another font.
Change of glyphs normally means a change in style of presentation,
while change in characters normally means a change in information.
There are gray areas and the definitions provided above are general,
approximate, and imprecise.
Character set: an inventory of characters with certain assigned values.
ASCII is a 7-bit character set that specifies which "character cell"
(byte value) corresponds to which informational unit.
Code Page: essentially synonymous with character set.
Font: A collection of glyphs. A specific font may be isomorphic with a
specific character set, containing only glyphs corresponding to
characters in that set, with these glyphs mapped to the same byte
values as the characters they are intended to represent. PostScript
fonts often contain additional (unmapped) characters. Most importantly,
PostScript fonts may sometimes be remapped by an operating environment,
which is what leads to the disorienting cross-environment mismatch that
spurred my original posting.
Fonts may be bitmapped or outline in format; a bitmapped format
corresponds to a particular size and weight for a particular device or
device resolution, while a single outline font is used to generate
multiple sizes as needed. Within an outline font system, different
weights (bold, semibold, italic, etc.) may be encoded as separate font
resources (separate outline files used to generate the glyphs) or may
all be generated from a single outline (slanting characters to make
"italics," fattening them for "bold," etc.).
Subject: 4.2. Fonts under DOS
I used a large assortment of fonts under DOS for intricate multilingual
work. My setup at that time consisted of a library of bitmapped fonts
that could be sent to my HP LaserJet II printer, as well as a set of
fixed-size, fixed-width screen fonts that were supported by my Hercules
Graphics Card Plus (not the same as Hercules Graphics; the "Plus"
included an ability to store 3072 screen glyphs and display any of
these together, while standard character-mode displays were normally
limited to 256 or 512 such entities).
Using XyWrite as a word processor, I would enter a "Mode" command to
change fonts and character sets simultaneously; this would make
different sets of screen glyphs available at the keyboard and would
insert a font-change command for my printer into the text stream. The
"Mode" and font-change commands were not displayed on the screen. The
result was not WYSIWYG, since I was limited to fixed-width screen
display and since I had far more printer glyphs available than the 3072
limit imposed by my video card; I used a brightness attribute to
indicate bold, I used the same screen font for different sizes of
printer fonts, etc. This worked and worked well, in that I could see
(for example) Russian, Greek, English, Polish, and other characters
simultaneously on the screen and I could print documents combining them.
Architecturally, what was going on was that the character sets (code
pages) and fonts were entirely isomorphic and were hard- coded. If I
put a particular Russian letter into cell 246 of my screen and printer
fonts, that character was always there, and any strategy that would let
me access this cell (remapped keyboards, numeric keypad) was guaranteed
always to find the same character.
Subject: 4.3. Windows
I recently began using PostScript fonts in Windows with AmiPro as my
word processor. These fonts came with printed cards indicating the
glyph mappings; I could look at the card and it would tell me that a
specific character lived in cell 246, and if I entered Alt-0246 at the
numeric keypad that glyph would appear on the screen. If I loaded the
font into Fontographer for Windows, these glyphs would be arrayed in
cells according to the map provided by Adobe with the fonts.
Fontographer also revealed that these fonts had other, "unmapped"
glyphs assigned to cells above 255.
Given what appeared to be a hard correspondence among what I saw in
Fontographer, what was printed in Adobe's maps, and what was displayed
when I entered something at the keyboard, I naively assumed that
PostScript fonts were operating much like my bitmapped fonts under DOS.
There were some obvious differences, the primary one being that glyphs
of different sizes were all drawn from the same font resource files
under PostScript, but it appeared as if a glyph lived in a certain cell.
Subject: 4.4. Differences between Windows and OS/2
This assumption was incorrect; PostScript fonts can be subdivided into
two types, one of which observes hard and invariant encodings similar
to those that apply to my bitmapped fonts, while the other represents a
completely different font mapping strategy. This difference became
apparent only when I attempted to share PostScript fonts between
Windows and OS/2 and got some unexpected results.
A PostScript font under Windows involves two files, a PFB (PostScript
Font Binary) file, which contains the PostScript instructions needed to
draw each glyph and some mapping information, and a PFM (Printer Font
Metrics) file, which encodes width and kerning information. A
PostScript font under OS/2 also uses the same PFB file, but instead of
the PFM file it uses an AFM (Adobe Font Metrics) file. The AFM and PFM
files contain much of the same basic information (although the AFM file
is somewhat more complete); the most important differences are in
format (AFM is plain text, PFM is binary) and use (OS/2 uses AFM,
Windows uses PFM).
Subject: 4.5. Installation under Windows and Win-OS/2
The OS/2 2.0 Font Palette tool (see below for changes to be introduced
with 2.1) by default installs fonts (both PFB and AFM files) into the
"\os2\dll" directory. Win-OS/2 by default installs PFB files into
"\psfonts" and PFM files into "\psfonts\pfm". These defaults can be
changed; since OS/2 and Win-OS/2 use the same PFB files, the user can
save disk space by allowing these to be shared (through installing into
the same directory, e.g., install OS/2 fonts into the "\psfonts"
directory instead of "\os2\dll".) Note that fonts must be intalled and
removed through the Font Palette; if you copy, move, or delete a font
file without using the Font Palette, the system configuration files are
not updated and all hell breaks loose.
Deleting fonts from Win-OS/2 causes the system to update the win.ini
file to remove references to the font, but does not delete any files
physically. Deleting fonts from the OS/2 Font Palette updates the
os2.ini configuration file and physically deletes the AFM and PFB files
from the disk. This means that if you are sharing PFB files between
OS/2 and Win-OS/2, you can delete a Win-OS/2 font without hurting
native OS/2 operations, since the PFB reamins installed where OS/2
thinks it is. But if you delete an OS/2 font using the Font Palette,
the PFB file is erased from the disk even though the win.ini file is
not updated, so that Win-OS/2 thinks it is still there.
Subject: 4.6. FontSpecific PostScript Encoding
Every PFB file contains an "encoding vector"; this is a plain text line
embedded near the head of the PFB file. Encoding vectors are of two
types: AdobeStandardEncoding and everything else. Adobe usually uses
the label "FontSpecific" for fonts that are not encoded according to
AdobeStandardEncoding, and I use it as a cover term here for any such
font.
If you look at the readable plain text information at the head of a
FontSpecific type font, it includes a range of text that begins:
/Encoding 256 array
followed by a bunch of lines, each of which includes a number (which
corresponds to a cell in the font layout) and the name of the glyph
that lives in that cell. The unreadable binary data below this array
specification lists the name of each glyph and the PostScript
instructions for how the glyph is to be drawn. There may be PostScript
code for drawing glyphs that are not included in the mapping array, but
only glyphs mentioned in the array specification are available to
applications.
FontSpecific type fonts are comparable to the bitmapped fonts I used
under DOS. Each character physically is assigned to a specific cell
within the font file and operating environments are not allowed to
remap these. The glyph in cell 246 will be the same in both Windows and
OS/2.
Subject: 4.7. AdobeStandardEncoding
AdobeStandardEncoding is a specific mapping of certain glyphs to
certain cells; in this respect it resembles FontSpecific encoding.
Because it is standardized, the array is not spelled out in the PFB
file; the line
/Encoding StandardEncoding def
tells Adobe Type Manager (ATM, either the Windows and Win-OS/2 version
or the native OS/2 version) that the encoding is "standard," and the
environments are expected to know what this standard is without having
the array spelled out in each font file.
Although AdobeStandardEncoding is a real mapping, there is an
importance difference between it and various FontSpecific mappings:
operating environments are expected to remap AdobeStandardEncoding
fonts according to their own requirements. That is, although
AdobeStandardEncoding does assign glyphs to cells, no operating
environment actually uses these assignments and any environment remaps
the glyphs before rendering them. Confusion arises because Windows and
OS/2 remap such fonts in different ways.
Subject: 4.8. AdobeStandardEncoding under Windows (and Win-OS/2)
An AdobeStandardEncoding font under Windows is remapped according to a
character map (code page) that MicroSoft calls Windows ANSI (can other
code pages be installed in Windows?). This determines which character
resides in which cell and the font is remapped so that glyphs and
characters will correspond. Since Fontographer for Windows is a Windows
application, it displays glyphs not in the cells in which they live
according to AdobeStandardEncoding, but in the cells to which they get
reassigned under the remapping to Windows ANSI. There is nothing
explicit in the PFB file that associates these characters with the
specific cells in which they appear under Windows.
Subject: 4.9. AdobeStandardEncoding under OS/2
OS/2 operates within a set of supported code pages; two system- wide
code pages are specified in the config.sys file and an application is
allowed to switch the active code page to any supported code page (not
just these two). DeScribe, for example, currently operates in code page
(CP) 850, which includes most letters needed for western European Latin
alphabet writing. CP 850 does not contain typographic quotes, en- and
em-dashes, and other useful characters. It does contain the IBM
"pseudographics," which are useful for drawing boxes and lines with
monospaced fonts.
When the user inputs a value (through the regular keyboard or the
numeric keypad), the application checks the active CP, looks up in an
internal table the name of the character that lives in that cell within
that CP, and translates it into a unique number that corresponds to one
of the 383 glyphs supported by OS/2 (the union of all supported code
pages). This number is passed to PM-ATM (the OS/2 ATM implementation),
which translate the glyph number into the glyph name that PostScript
fonts expect and searches the font for that name. The system never
looks at where a glyph is assigned under the AdobeStandardEncoding
array; rather, it scans the font looking for the character by name and
gives it an assignment derived from the active code page. This is the
remapping that OS/2 performs on AdobeStandardEncoding type fonts.
As a result, a situation arises where, for example, <o+diaeresis> is
mapped to cell 246 under Windows ANSI but to cell 148 under CP 850.
Using the identical PFB file, this glyph is accessed differently in the
two operating environments.
Subject: 4.10. Consequences for OS/2 users
If your font has a FontSpecific encoding, there are no unexpected
consequences; the same glyphs will show up at the same locations in
both Windows (Win-OS/2) and native OS/2. Regardless of what the active
code page is, if the font has a FontSpecific encoding OS/2 goes by cell
value; a specific glyph is hard-coded to a specific cell and OS/2 will
give you whatever it finds there, even if what it finds disagrees with
what the active code page would normally predict. In other words,
FontSpecific encoding means "ignore the mapping of the active code page
and rely on the mapping hard-coded into the font instead."
If your font has an AdobeStandardEncoding encoding, the following
details obtain:
1) The same PFB file may have glyphs that are accessible in one
environment but not another. For example, if DeScribe thinks it is
operating in CP 850, there is no access to typographic quotes, even if
those do occur in the PFB file and even if Windows can find them in the
same exact font file. DeScribe could switch code pages, but if the
application isn't set up to do so (and DeScribe currently isn't), those
characters are absolutely inaccessible to the user.
2) If the active code page includes a character that isn't present in
the font, OS/2 has to improvise. For example, AdobeStandardEncoding
fonts do not normally include the IBM pseudographics, yet the user who
inputs the character value for one of these sends the system off to
look for it. As described above, OS/2 first checks the active font for
the glyph name that corresponds to that character and, if it finds it,
displays it. If the glyph isn't found, OS/2 looks to the system Symbol
font. This is not reported back to the user in DeScribe; if I have
Adobe Minion active (AdobeStandardEncoding, no information anywhere in
the font files for pseudographics) and input a pseudographic character,
DeScribe tells me it is still using Adobe Minion, even though it has
fetched the character it displays and prints from the Symbol font, a
different font resource file.
Subject: 4.11. Advice to the user
OS/2's code page orientation provides some advantages, in that it
separates the character set (code page) mapping from the encoded font
mapping. The main inconvenience isn't a loss of function, but a
disorientation as users become accustomed to the new paradigm.
If you need a glyph that you know is in your PFB file but that isn't in
the active code page (and if you can't change code pages within your
application), you can't get at it in OS/2 without tampering with the
font files. To tamper, you can use font manipulation tools to
redesignate the PFB file as FontSpecific ("Symbol" character set to
Fontographer). If you then map the glyphs you need into one of the
lower 256 cells (with some limitations), they will be accessible in all
environments. The Fontographer manual does not explain what the
"Symbol" character encoding label really does, it just tells you not to
use it except for real symbol fonts. In fact you should use it for any
font that will not correspond in inventory to the code page supported
by your application, which means any non-Latin fonts.
You do not have to recode all your fonts, and you wouldn't normally
want to do so, since Fontographer hinting is not nearly as good as
Adobe's own hand-tuning and regenerating a font regenerates the hints.
All you have to do is make sure you have one FontSpecific type font
installed that includes your typographic quotes, etc. for each typeface
you need. Within DeScribe, you can then write a macro that will let you
switch fonts, fetch a character, and switch back, thereby allowing you
to augment any group of fonts with a single, shared set of typographic
quotes (or whatever) that you put in a single FontSpecific font.
Alternatively, OS/2 also supports CP 1004, which does contain
typographic quotes and other characters used for high-quality
typography, but the user may not be able to convince an application to
invoke this code page if it was not designed to do so.
You can have any number of FontSpecific fonts installed, which means
that there is a mechanism for dealing with unsupported character sets
(code pages).
You can also tinker with the font files to try to trick the operating
system. For example, using Fontographer or other utilities, you can
change the name assigned to a glyph description within the PFB file. If
you want to use AdobeStandardEncoding and you want to see a specific
glyph at a specific cell when DeScribe thinks it's using CP 850, you
have to make sure that the name assigned to the description of that
glyph is what DeScribe expects to find. OS/2 doesn't care whether, say,
<o+diaeresis> really looks like <o> with two dots over it, as long as
it bears the right name.
This second approach is obviously far more complex and provides much
more opportunity for error. Its advantage is that OS/2 does not support
case conversion and sorting (other than in machine order) for
unsupported code pages, since these operations depend on character
names. Keeping supported names from supported code pages while changing
the artwork is one way to maintain order and case correspondences while
increasing the range of glyphs actually supported. I have not
experimented with this approach, since the use I would get out of the
adding functionality (over the FontSpecific encoding approach) is not
worth the amount of effort required.
Subject: 4.12. OS/2 2.1 and beyond
OS/2 2.1 will change some aspects of font handling. First, OS/2 2.0
GA+SP has a bug that can cause OS/2 to crash when an AFM file with more
than 512 kern pairs is read. This is fixed in 2.1. (This bug is
separate from a design limitation in MicroSoft Windows that causes
large kern tables to be read incorrectly. This problem is still under
investigation; watch this space for a report.)
Fonts in 2.1 will be installed by default into the "\psfonts" directory,
so that they will normally be shared with Win-OS/2 fonts. (The user will
still be able to specify a directory; all that will change is the
default). The user will also be able to instruct the Font Palette not to
delete font files when fonts are uninstalled, so as to avoid clobbering
a Win-OS/2 font by removing it from native OS/2 use through the Font
Palette (although the default will still be to delete the physical font
files).
OS/2 will stop using AFM files and will replace these with OFM files, a
binary metrics file (different from PFM) that OS/2 will compile from
the AFM file during font installation. This will speed font loading,
since the system will not have to parse a plain text metrics file.
Additionally, the OS/2 PostScript printer driver used to install its
own, large font files, but will now use the OFM and PFB files, thereby
saving 50k-200k of disk space per installed font outline.
IBM's long-term goal is to replace the 383-entity inventory of
supported glyphs with Unicode. This is very much a long-term goal and
there is not even a hint of when it might become available. It has its
own problems, stemming from the fact that Unicode is essentially a
character standard and glyph and character inventories may differ is
assorted ways, but it will be a significant step in the proverbial
right direction.
