diff options
Diffstat (limited to 'help/comp-fonts-FAQ/comp.fonts_FAQ:_OS_2_Info')
-rw-r--r-- | help/comp-fonts-FAQ/comp.fonts_FAQ:_OS_2_Info | 420 |
1 files changed, 420 insertions, 0 deletions
diff --git a/help/comp-fonts-FAQ/comp.fonts_FAQ:_OS_2_Info b/help/comp-fonts-FAQ/comp.fonts_FAQ:_OS_2_Info new file mode 100644 index 0000000000..745535ca00 --- /dev/null +++ b/help/comp-fonts-FAQ/comp.fonts_FAQ:_OS_2_Info @@ -0,0 +1,420 @@ +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: norm@ora.com (Norman Walsh) +Newsgroups: comp.fonts,comp.answers,news.answers +Subject: comp.fonts FAQ: OS/2 Info +Supersedes: <font-faq-9_817479312@ora.com> +Followup-To: poster +Date: 14 Aug 1996 10:34:55 -0400 +Organization: O'Reilly and Associates, Inc. +Lines: 397 +Sender: norm@ruby.ora.com +Approved: news-answers-request@MIT.Edu +Distribution: world +Expires: 27 Sep 1996 14:34:08 GMT +Message-ID: <font-faq-9_840033248@ora.com> +References: <font-faq-1_840033248@ora.com> +Reply-To: norm@ora.com (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. + |