========================================================================= Date: Wed, 9 Jan 91 21:25:04 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: +++ Changed X.430-Header: +++ x *** GATEWAY INFO: "POSTMAN at DFNGATE" was the real originator of this note. TO: x FROM: x MESSAGE ID: ;910108185228 x BODY TYPE: IA5TEXT From: POSTMASTER@RZ.UNI-HILDESHEIM.DBP.DE Subject: review review ========================================================================= Date: Wed, 16 Jan 91 05:39:54 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Teresa A. Ehling" Subject: Naming of Non-CM Fonts **************************************************************** A RECOMMENDATION FOR THE NAMING of NON-CM FONTS USED IN TeX Now that increasing use is being made of non-CM fonts in TeX, it is important that standards be developed for the names used to refer to such fonts in TeX input. Without such a standard, TeX cannot locate the appropriate font metric information, and DVI processing programs connot locate the required font outlines or bitmaps, or use the correct font name to invoke the correct printer-resident fonts. This lack of codification has proved to be a major source of frustration when DVI files are ported from one computer system to another, as is common when publishing journal articles and books from author-supplied material. As it stands now, each project to be run out requires customization, compelling the typesetter to set up yet another new font name translation table that maps names used in TeX to file names. And this usually requires consulting with the author to determine just what the font names in the manuscript mean. Perhaps more seriously, without a uniform naming convention, it may happen that the DVI processing program and TeX have conflicting notions about what fonts are being referred to-- with disasterous consequences. Without a naming convention then, DVI files are not truly "device independent" since they are tied to the naming convention used on a particular computer system. As a basis for our proposal, we quote from the "The TeXbook" (p.278): "The syntax for in \font is not standard in TeX because different operating systems have different conventions. You should ask your local system wizards for details on just how they have decided to implement filenames. However, the following principles should hold universally: A should consist of followed by explicit character tokens (after expansion). A sequence of six or fewer ordinary letters and/or digits followed by a space should be a file name that works in essentially the same way on all installations of TeX...." Consequently: * We recommend that where a standard naming convention for a font library already exists that fits into the scheme advocated in "The TeXbook", then that convention should be adopted for use with TeX and DVI converters. Presently, many of the non-CM fonts called for by users of TeX are PostScript outline fonts, either printer resident or in downloadable form. Adobe Systems was already inspired to invent a naming convention for the fonts in their library for use on computers that cannot handle long file names. In their library, file names are assigned to fonts by (manually) contracting the font family name and appending standard modifiers for bold (b), italic (i), bold-italic (bi), light (l), oblique (o), narrow (n), condensed (c), and so on. Thus information about the font with PostScript FontName 'Times-BoldItalic', for example, is stored in files with the name 'tibi'. An extension of the file name indicates what type of information is in the file. Commonly used extensions are .afm (for Adobe font metric information), .tfm (for TeX font metric information), .pfm (for MicroSoft Windows printer font metric information), .pfb (for printer font binary), and .pfa (for printer font ASCII). Adobe's Fontdownloader limits the file name to six characters, which conforms exactly to the recommendation in "The TeXbook". It seems logical then that: * When using Adobe PostScript outline fonts in TeX, one should simply follow this naming convention. (There is presently no conflict with CM font names since none of the fonts in the Adobe font library have names starting with the letters 'cm'.) One possible complication arises from the practice of remapping character codes in non-CM fonts to lie in positions that are used by TeX in some CM font. One should be able to distinguish between a font that is used verbatim and one that has been remapped: * We recommend that the suffix 'm' be appended to a fontname when a remapped version is intended. This is not completely unambiguous since the font can be remapped in different ways, but it will usually be obvious what is intended. Thus a regular font would normally be remapped to the ordinary text (roman) encoding of TeX (as for cmr10), an italic font would be remapped to TeX's italic encoding (as for cmti10), while a symbol font would be remapped to TeX's symbol encoding (as in cmsy10). * We recommend that the 'm' be used as a suffix, NOT as a prefix so that related fonts continue to appear together in a sorted list. (Adding the suffix to a name with six characters brings it to seven, but even the most limiting file systems these days allow up to eight characters.) It should be noted that the issue of remapping is now becoming less important as users are switching to TeX 3.0, which supports fonts with 256 character codes. But it seems likely that continued used will be made of remapping for specialized purposes. * We also recommend that no prefix (e.g. 'ps') be attached to fontnames since this wastes two precious characters out of the six (or perhaps eight) that are available on some systems. We welcome your comments on this proposal and look foward to the utilization of a viable font naming standard in the near future. We welcome your comments on this proposal and look foward to the utilization of a viable font naming standard in the near future. Berthold K.P. Horn Artificial Intelligence Lab MIT bkph@ai.mit.edu Teresa A. Ehling The MIT Press Cambridge, Mass. ehling@mitvma.mit.edu ADDENDUM: Names of Some Commonly used Adobe Outline Fonts --------------------------------------------------------- ag AvantGarde-Book ago AvantGarde-BookOblique agd AvantGarde-Demi agdo AvantGarde-DemiOblique bkl Bookman-Light bkli Bookman-LightItalic bkd Bookman-Demi bkdi Bookman-DemiItalic cll Clarendon-Light cl Clarendon clb Clarendon-Bold com Courier coo Courier-Oblique cobo Courier-BoldOblique cob Courier-Bold hv Helvetica hvo Helvetica-Oblique hvb Helvetica-Bold hvbo Helvetica-BoldOblique hvc Helvetica-Condensed hvco Helvetica-Condensed-Oblique hvcb Helvetica-Condensed-Bold hvcbo Helvetica-Condensed-BoldObl lmi LucidaMath-Italic lms LucidaMath-Symbol lme LucidaMath-Extension nbr NewBaskerville-Roman nbi NewBaskerville-Italic nbb NewBaskerville-Bold nbbi NewBaskerville-BoldItalic ncr NewCenturySchlbk-Roman nci NewCenturySchlbk-Italic ncb NewCenturySchlbk-Bold ncbi NewCenturySchlbk-BoldItalic new NeuzeitS-Book newh NeuzeitS-BookHeavy por Palatino-Roman poi Palatino-Italic pob Palatino-Bold pobi Palatino-BoldItalic sy Symbol tir Times-Roman tii Times-Italic tib Times-Bold tibi Times-BoldItalic zcmi ZapfChancery-MediumItalic zd ZapfDingbats ========================================================================= Date: Wed, 16 Jan 91 12:20:33 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Naming of Non-CM Fonts I don't know if all members of this list had got Karl Berrys proposal for font naming. It follows below, and I just wonder what is missing? It has a very good structure and seems to work fine for most (if not to say for all) important operating systems. -------------------- Original message follows: -------------------- >Date: Mon, 2 Jul 90 12:51:10 EDT >From: Karl Berry >Message-Id: <9007021651.AA05764@aten.cs.umb.edu> >To: tex-archive@SCIENCE.UTAH.EDU, pzf5hz%drueds2.bitnet@RELAY.CS.NET, > bk4%dhdurz1.bitnet@RELAY.CS.NET >Subject: font names I've taken Don (Hosek)'s suggestion for font names, and Frank & Rainer's tables in the latest TUGboat, and applied them to all the fonts I've used with TeX: the 25 standard PostScript fonts on the LaserWriter; the fonts from the Waterloo archive; fonts converted with Sun's TypeScaler system; and hand-edited bitmaps from Bigelow&Holmes. To recap, the basic scheme is: [device][foundry][weight][expansion][shape][size] D F M W E H S First I'll give all the extensions to Frank & Rainer's tables I had to make, and then all the (mostly boring) font names. My additions are in square brackets. I would also like to propose two changes to what was published in TUGboat: use `ti' instead of `it' for text italic, following DEK; and change their use of `expanded' to `extended'. As I understand it, typographic tradition is that `condensed' and `extended' fonts are versions that are designed by hand; `narrow' and `expanded' fonts are versions that are done merely geometrically. (Perhaps I'm wrong, though.) In any case, we must be clear about this. The only fonts for the names got too long were the Lucida bitmaps. This particular case doesn't matter so much, since the bitmaps aren't distributed, and probably will never be. So perhaps we shouldn't worry about it. I am about to distribute a set of TFM's for the PostScript fonts, plus a few TeX macros, that get all the accents, ligatures, etc. in the standard encoding right; I know dvips can do this with vfm files, but they aren't necessary in this case. If all is well, I will distribute with the names I've given here. karl@cs.umb.edu foundry ------- bh = Bigelow & Holmes bs = Bitstream i = ITC ps = Adobe s = Sun (Folio) family ------ ag = Avant Garde ao = Antique Olive at = American Typewriter bb = Bembo bg = Benguiat bk = Bookman bv = Baskerville bw = Broadway cb = Cooper Black cr = Courier cs = Century Schoolbook hv = Helvetica gm = Garamond gs = Gill Sans lc = Lucida nc = New Century Schoolbook op = Optima pl = Palatino rw = Rockwell tm = Times un = Univers uy = University zc = Zapf Chancery special ------ symbol = PostScript Symbol zdingb = Zapf Dingbats shape ------ n = normal [br = bright] [ol = outline] sc = small caps [sh = shadow] sl = slanted [or oblique] [ss = sans serif] tt = typewriter it [ti] = text italic u = unslanted italic weight ------- ultra light = ul extra light = el light = l semi light = sl [book = bk] medium = m [demi bold = db] semi bold = sb bold = b extra bold = eb ultra bold = ub expansion --------- ultra condensed (50%) = uc extra condensed (62.5) = ec condensed (75) = c semi condensed (87.5) = sc medium (100) = m semi expanded (112.5) = sx expanded (125) = x extra expanded (150) = ex ultra expanded (200) = ux repeat, with narrow = n and extended = t condensed and extended are by hand; narrow and expanded are automatic. (LaserWriter) psagbk AvantGarde-Book psagbksl AvantGarde-BookOblique psagd AvantGarde-Demi psagdsl AvantGarde-DemiOblique psbkd Bookman-Demi psbkdti Bookman-DemiItalic psbkl Bookman-Light psbklti Bookman-LightItalic pscrb Courier-Bold pscrbsl Courier-BoldOblique pscrsl Courier-Oblique pscr Courier pshvb Helvetica-Bold pshvbsl Helvetica-BoldOblique pshvsl Helvetica-Oblique pshv Helvetica pshvbn Helvetica-Narrow-Bold pshvbnsl Helvetica-Narrow-BoldOblique pshvnsl Helvetica-Narrow-Oblique pshvn Helvetica-Narrow psncb NewCenturySchlbk-Bold psncbti NewCenturySchlbk-BoldItalic psncti NewCenturySchlbk-Italic psncr NewCenturySchlbk-Roman psplb Palatino-Bold psplbti Palatino-BoldItalic psplti Palatino-Italic psplr Palatino-Roman pssymbol Symbol pstmb Times-Bold pstmbti Times-BoldItalic pstmti Times-Italic pstmr Times-Roman pszcti ZapfChancery-MediumItalic pszdingb ZapfDingbats (Waterloo; faces I can't identify are just labelled `xx') xx abb atr ame atrb ameb atsl amei agm avt xx bar bgr beg bwb brd bwe bre bvr bsq xx car csr cen csb cenb cssl ceni csol ceno cssh cens zcn cha zcb chab zcsl chai cbr coo xx cor xx cyr xx dea igmr gar (ITC Garamond) igmb garb igmsl gari igmol garo igmsh gars xx gas gsb gil18 unm glx hvmc helc hvsh hels xx helt xx oen aor oli opr opt opb optb opsl opti opol opto opsh opts uyr orn plr pal xx pcs xx pic xx pre xx qik rwr roc rwb rocb rwsl roci tmr rom tmb romb tmti romi xx scr xx spc (Sun/Folio) sagbk AvantGarde-Book sagbksl AvantGarde-BookOblique sagd AvantGarde-Demi sagdsl AvantGarde-DemiOblique (ditto for Bookman, Courier, Helvetica, Times) sbbr Bembo sbbti Bembo-Italic sbbb Bembo-Bold sbbbti Bembo-BoldItalic sgsm GillSans sgsti GillSans-Italic sgsb GillSans-Bold sgsbti GillSans-BoldItalic slcss LucidaSans slcssti LucidaSans-Italic slcssb LucidaSans-Bold slcssbti LucidaSans-BoldItalic slcbr LucidaBright slcbrti LucidaBright-Italic slcbrdb LucidaBright-Demi slcbrdti LucidaBright-DemiItalic [lost the `b' in `db'] slcsstt LucidaSans-Typewriter slcsstti LucidaSans-TypewriterItalic (hand-edited bitmaps from B&H; the names are longer than 8 characters, so remove the `bh'? Compress to ls instead of lcss?) bhlcr10 Lucida roman bhlcti10 Lucida italic bhlcb10 Lucida bold bhlcbi10 Lucida bold italic bhlcss10 Lucida sans bhlcssi10 Lucida sans italic bhlcssb10 Lucida sans bold bhlcssbi10 Lucida sans bold italic --- end ========================================================================= Date: Wed, 16 Jan 91 12:20:33 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Naming of Non-CM Fonts I don't know if all members of this list had got Karl Berrys proposal for font naming. It follows below, and I just wonder what is missing? It has a very good structure and seems to work fine for most (if not to say for all) important operating systems. -------------------- Original message follows: -------------------- >Date: Mon, 2 Jul 90 12:51:10 EDT >From: Karl Berry >Message-Id: <9007021651.AA05764@aten.cs.umb.edu> >To: tex-archive@SCIENCE.UTAH.EDU, pzf5hz%drueds2.bitnet@RELAY.CS.NET, > bk4%dhdurz1.bitnet@RELAY.CS.NET >Subject: font names I've taken Don (Hosek)'s suggestion for font names, and Frank & Rainer's tables in the latest TUGboat, and applied them to all the fonts I've used with TeX: the 25 standard PostScript fonts on the LaserWriter; the fonts from the Waterloo archive; fonts converted with Sun's TypeScaler system; and hand-edited bitmaps from Bigelow&Holmes. To recap, the basic scheme is: [device][foundry][weight][expansion][shape][size] D F M W E H S First I'll give all the extensions to Frank & Rainer's tables I had to make, and then all the (mostly boring) font names. My additions are in square brackets. I would also like to propose two changes to what was published in TUGboat: use `ti' instead of `it' for text italic, following DEK; and change their use of `expanded' to `extended'. As I understand it, typographic tradition is that `condensed' and `extended' fonts are versions that are designed by hand; `narrow' and `expanded' fonts are versions that are done merely geometrically. (Perhaps I'm wrong, though.) In any case, we must be clear about this. The only fonts for the names got too long were the Lucida bitmaps. This particular case doesn't matter so much, since the bitmaps aren't distributed, and probably will never be. So perhaps we shouldn't worry about it. I am about to distribute a set of TFM's for the PostScript fonts, plus a few TeX macros, that get all the accents, ligatures, etc. in the standard encoding right; I know dvips can do this with vfm files, but they aren't necessary in this case. If all is well, I will distribute with the names I've given here. karl@cs.umb.edu foundry ------- bh = Bigelow & Holmes bs = Bitstream i = ITC ps = Adobe s = Sun (Folio) family ------ ag = Avant Garde ao = Antique Olive at = American Typewriter bb = Bembo bg = Benguiat bk = Bookman bv = Baskerville bw = Broadway cb = Cooper Black cr = Courier cs = Century Schoolbook hv = Helvetica gm = Garamond gs = Gill Sans lc = Lucida nc = New Century Schoolbook op = Optima pl = Palatino rw = Rockwell tm = Times un = Univers uy = University zc = Zapf Chancery special ------ symbol = PostScript Symbol zdingb = Zapf Dingbats shape ------ n = normal [br = bright] [ol = outline] sc = small caps [sh = shadow] sl = slanted [or oblique] [ss = sans serif] tt = typewriter it [ti] = text italic u = unslanted italic weight ------- ultra light = ul extra light = el light = l semi light = sl [book = bk] medium = m [demi bold = db] semi bold = sb bold = b extra bold = eb ultra bold = ub expansion --------- ultra condensed (50%) = uc extra condensed (62.5) = ec condensed (75) = c semi condensed (87.5) = sc medium (100) = m semi expanded (112.5) = sx expanded (125) = x extra expanded (150) = ex ultra expanded (200) = ux repeat, with narrow = n and extended = t condensed and extended are by hand; narrow and expanded are automatic. (LaserWriter) psagbk AvantGarde-Book psagbksl AvantGarde-BookOblique psagd AvantGarde-Demi psagdsl AvantGarde-DemiOblique psbkd Bookman-Demi psbkdti Bookman-DemiItalic psbkl Bookman-Light psbklti Bookman-LightItalic pscrb Courier-Bold pscrbsl Courier-BoldOblique pscrsl Courier-Oblique pscr Courier pshvb Helvetica-Bold pshvbsl Helvetica-BoldOblique pshvsl Helvetica-Oblique pshv Helvetica pshvbn Helvetica-Narrow-Bold pshvbnsl Helvetica-Narrow-BoldOblique pshvnsl Helvetica-Narrow-Oblique pshvn Helvetica-Narrow psncb NewCenturySchlbk-Bold psncbti NewCenturySchlbk-BoldItalic psncti NewCenturySchlbk-Italic psncr NewCenturySchlbk-Roman psplb Palatino-Bold psplbti Palatino-BoldItalic psplti Palatino-Italic psplr Palatino-Roman pssymbol Symbol pstmb Times-Bold pstmbti Times-BoldItalic pstmti Times-Italic pstmr Times-Roman pszcti ZapfChancery-MediumItalic pszdingb ZapfDingbats (Waterloo; faces I can't identify are just labelled `xx') xx abb atr ame atrb ameb atsl amei agm avt xx bar bgr beg bwb brd bwe bre bvr bsq xx car csr cen csb cenb cssl ceni csol ceno cssh cens zcn cha zcb chab zcsl chai cbr coo xx cor xx cyr xx dea igmr gar (ITC Garamond) igmb garb igmsl gari igmol garo igmsh gars xx gas gsb gil18 unm glx hvmc helc hvsh hels xx helt xx oen aor oli opr opt opb optb opsl opti opol opto opsh opts uyr orn plr pal xx pcs xx pic xx pre xx qik rwr roc rwb rocb rwsl roci tmr rom tmb romb tmti romi xx scr xx spc (Sun/Folio) sagbk AvantGarde-Book sagbksl AvantGarde-BookOblique sagd AvantGarde-Demi sagdsl AvantGarde-DemiOblique (ditto for Bookman, Courier, Helvetica, Times) sbbr Bembo sbbti Bembo-Italic sbbb Bembo-Bold sbbbti Bembo-BoldItalic sgsm GillSans sgsti GillSans-Italic sgsb GillSans-Bold sgsbti GillSans-BoldItalic slcss LucidaSans slcssti LucidaSans-Italic slcssb LucidaSans-Bold slcssbti LucidaSans-BoldItalic slcbr LucidaBright slcbrti LucidaBright-Italic slcbrdb LucidaBright-Demi slcbrdti LucidaBright-DemiItalic [lost the `b' in `db'] slcsstt LucidaSans-Typewriter slcsstti LucidaSans-TypewriterItalic (hand-edited bitmaps from B&H; the names are longer than 8 characters, so remove the `bh'? Compress to ls instead of lcss?) bhlcr10 Lucida roman bhlcti10 Lucida italic bhlcb10 Lucida bold bhlcbi10 Lucida bold italic bhlcss10 Lucida sans bhlcssi10 Lucida sans italic bhlcssb10 Lucida sans bold bhlcssbi10 Lucida sans bold italic --- end ========================================================================= Date: Wed, 16 Jan 91 22:18:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Naming of Non-CM Fonts As was pointed out earlier in a note to driv-l, Karl Berry has composed a font naming scheme which covers most cases. (going through the Adobe type library, I found a handful of exceptions). The one thing not covered is character set mapping, which is unfortunate, but also a side affect of the tight naming in an 8 character space (a six character space is useful for most but not all fonts and leaves no room for design sizes, but that's OK since there are few if any machines left with a six character restriction on file names). My personal feeling on remapped fonts is that remappings should be to the standard character codes determined by TUG for extended character mappings (a text mapping was created at Cork last fall, but I personally find it inadequate for my type design needs---I need more empty spaces for arbitrary ligatures). -dh ========================================================================= Date: Fri, 18 Jan 91 14:23:56 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Thomas Spellman To help minimize the ability of network WORMS to spread, all the lists on TAMVM1 have been changed to reject files such as execs and modules, normal mail messages will not be effected. This should be a transparent change for most of you. If it is not, contact me directly. Thomas R. Spellman POSTMASTER, TAMVM1 X226TS@TAMVM1.BITNET X226TS@TAMVM1.TAMU.EDU ========================================================================= Date: Fri, 18 Jan 91 14:59:14 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jerry Leichter Subject: Naming Fonts: A Revolutionary Proposal All the proposals I've seen so far assume that we will have to live the the 8-character filename limitation of a number of systems forever. I see no reason to accept such a limitation. The TeXbook makes it quite clear that the argument to \font is system-specific. In effect, what this says is that you need to check your particular version of TeX to figure out what it means. I see no reason why this argument needs to be a filename. Many DVI drivers today already support a "font substitution" file. I'd like to suggest that TeX implementations do the same. A very simple implementa- tion would just do simple 1-1 mapping of input names to real file names. A more complex one could have wildcards or whatever. Anything not mapped by the font substitution file would remain as entered, so existing TeX files could, if the system were configured right, continue to work unchanged. Note that if we can agree on a standard set of possible transformations (which should be pretty easy), the actual code needed would be system-independent. All that would be needed on individual systems would be a new table file. Even much of the table file - the "left hand sides" of transformations - could and should be system-independent. Note also that the transformation table could be used to specify the directory pre- or post-fixes needed for a particular system. Today, much of the system- specific code in TeX is dedicated to filename hacking. If the transformations available were sufficient powerful - and again, I don't think it would be that hard to make them so - that system-specific code could be eliminated. Modi- fying a transformation table is a lot easier than creating code. (In fact, I see no reason why the transformation code could not also be used to create the actual file specs for other files, such as format and dvi files.) I'd expect drivers to use the transformation code and table, too. Again, more code that can be shared rather than re-invented. (Also, there's "existing practice" in some drivers that could be used as a basis.) Human beings should not be called upon to live within the constraints of machines. Machines don't care what names look like, and they are really good at doing repetitive simple transformations (e.g., Bookman -> bk). People DO care, and are notoriously bad at doing pointless things. Let's try and design for future systems (and for people), not for relics of the past. -- Jerry PS: I'm sure one response to this message will be: "That's fine for the future, but we need a short-term fix now". "Short term fixes" in this busi- ness, especially those that become embedded in code on large numbers of sys- tems, tend to be anything but. The time to do this right is NOW, not after a hacked-together solution that more-or-less works much of the time becomes entrenched. -- J ========================================================================= Date: Fri, 18 Jan 91 15:01:37 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: Warning -- original Sender: tag was From: Bart Childs Subject: WORMS ... Tom if you do the message again, the word is `affected' not `effected'. The changes you are making are regrettably the kind that must be made today. Bart Childs ========================================================================= Date: Fri, 18 Jan 91 17:20:24 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Naming Fonts: A Revolutionary Proposal In-Reply-To: Message of Fri, 18 Jan 91 14:59:14 EDT from Jerry, et al., I agree with your proposal with one exception: You seem to feel that the font remapping needs to be built into TeX itself. There isn't a reason why such a remapping cannot be built on top of TeX, much like the new LaTeX font scheme. (I must confess that I don't know much about this scheme. Perhaps someone else could provide details on it.) By building such a scheme on top of TeX, no changes are necessary to TeX. Thus, the implementation can be done now. When I first saw Karl Berry's approach I did not like it. It seemed to be far too cryptic. However, when it is viewed as part of a layered approach to accessing fonts, it is a very important piece: It simplifies the mapping of "user-level" font names to "system-level" names by giving a standard for deriving these "system-level" names. ---Tom Reid ========================================================================= Date: Sat, 19 Jan 91 09:28:23 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jerry Leichter Subject: Re: Naming Fonts: A Revolutionary Proposal [doing it in TeX] [Tom Reid writes:] I agree with your proposal with one exception: You seem to feel that the font remapping needs to be built into TeX itself. There isn't a reason why such a remapping cannot be built on top of TeX, much like the new LaTeX font scheme. (I must confess that I don't know much about this scheme. Perhaps someone else could provide details on it.) By building such a scheme on top of TeX, no changes are necessary to TeX. Thus, the implementation can be done now. There are a couple of problems with this approach: a) Not everyone uses LaTeX or Plain or any one format. There are many different format files out there, each with its own idea of how to specify fonts at the user level. I don't see them EVER all being updated to include a new font selection scheme. b) The new LaTeX font scheme - at least what I know of it - provides the end user with a simple, logical way to specify different font properties. This is very different from a method for finding TFM files. For one thing, if it's going to be useful most of it will necessarily be machine-independent. I don't see it being used to do things like adding directory strings. Or, for another example: Many systems today DON'T have silly limits on file name lengths. Why should a system on which Bookman-Italic.TFM is a valid name not use it, just because some other system has to use bkti.tfm? But a font trans- lator written in TeX could not handle both. c) To contradict (b), since TeX is Turing-equivalent, any computation built in Web code COULD be implemented in TeX. A TeX program COULD read a table file and use it to drive translations. However, low-level string manipula- tion is difficult to do in TeX and usually quite slow; reading a table file would be difficult to do quickly; and generating useful error messages is notoriously difficult, especially once you do some optimizations to try and get reasonable performance. d) Code written in TeX could not be shared with DVI drivers. Now, if all that came out of TeX were \font's for the real, local filenames, then you might think the drivers wouldn't need access to the translations. But what happens in the case of an error? If I wrote and think in terms of Bookman-Italic, I don't want to deal with error messages phrased in terms of bkti. e) TeX code is harder to make really flexible, and much harder to update when (as always) it turns out not to be flexible enough. New fonts will continue to come along; they'll have to be dealt with. Some won't fit easily into any simple, logical scheme we can divise today. The transformations that should be available to someone writing entries in a transformation table should be quite powerful so that the code implementing it almost never needs to be changed. This kind of power and flexibility is extremely difficult to obtain in TeX. -- Jerry ========================================================================= Date: Mon, 21 Jan 91 12:36:33 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Andrew Dobrowolski Subject: mail list update Please replace John Gourlay's address on your electronic mailing list with my address. I have taken over some of John's functions. Thank you in advance. For the record, I am Andrew Dobrowolski, Arbortext Inc., aed@arbortext.com ========================================================================= Date: Tue, 22 Jan 91 17:06:51 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Naming Fonts: A (Counter-)Revolutionary Proposal In-Reply-To: Jerry Leichter's message of Fri, 18 Jan 91 14:59:14 EDT <9101182134.AA11220@june.cs.washington.edu> There is no reason why Karl's proposal should be considered as a confining restriction. Here at UnixTeX, we are making up scripts to provide for the short names for those who need them, and using symbolic links for those who don't. As a general---perhaps even an absolute---rule, those who need short names can't use symbolic links, so that we have it both ways. (How on earth the computing third world lives without symbolic links, I don't know.) I agree that the silly restriction on name-length has to go, but we can accommodate both during the transition period. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ========================================================================= Date: Thu, 24 Jan 91 01:08:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: better late than never Well, amendments 9-11 have been sent out to the voting members; they may be obtained via mailserv by sending the following text to mailserv@ymir.claremont.edu send [tex.dvi-standard]amendment.XXX where XXX is the amendment number. FTP people may get the files from [anonymous.tex.dvi-standard] on ymir.claremont.edu -dh ========================================================================= Date: Thu, 24 Jan 91 01:10:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Secretary for the group (was RE: re:Joachim's comment) Long ago, Bernard Gaulle said, >But it seems that Don is frequently out of this list. Therefore >we probably >need a co-manager or moderator. Why not, you, Joachim ? I agree, it would be nice to have someone who would help in things like keeping track of amendments and getting them out to the group etc. Is there a volunteer for this? -dh ========================================================================= Date: Thu, 24 Jan 91 02:02:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: DVI standard draft status I've just finished fixing some more typos in the level 0 standard v0.4a (it's now 0.04b). This file is available by mailserv@ymir.claremont.edu by sending the command SEND [TEX.DVI-STANDARD]LEVEL0-DRAFT.TEX FTP users can get the file from [anonymous.tex.dvi-standard] -dh ========================================================================= Date: Thu, 24 Jan 91 19:03:58 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Secretary for the group (was RE: re:Joachim's comment) > >But it seems that Don is frequently out of this list. Therefore > >we probably > >need a co-manager or moderator. Why not, you, Joachim ? > > I agree, it would be nice to have someone who would help in > things like keeping track of amendments and getting them out to > the group etc. Is there a volunteer for this? I have the complete stuff already within RCS to keep track of all the changes. I may therefore do it. I'm able to make the stuff available in the Bitnet Listserver at DHDURZ1. It must be put in an ftp site by someone else. Of course I may mail it to the respective person. Joachim Schrod ========================================================================= Date: Thu, 24 Jan 91 15:02:42 MST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: Re: Naming of Non-CM Fonts In-Reply-To: Your message of Wed, 16 Jan 91 05:39:54 EST I welcome the proposal from Berthold K.P. Horn and Teresa A. Ehling on getting short standard names for Adobe fonts adopted universally. I worked on this problem in December as part of a software effort to expand my PLOT79 graphics system to support PostScript fonts, and settled on a mapping file to handle the reduction of a name like AGaramondExp-SemiboldItalic to a six-char version that can be used portably. The problem is, this job cannot be automated. In December, the Adobe font collection had 751 .afm files, and trying various schemes, such as using only the upper-case letters from the full font names produces either names that are too long, or which conflict with others: Length Abbreviation Full Font Name 11 GBBBMRKSJHZ GothicBBB-Medium-83pv-RKSJ-H.Zba 10 GBBBMRKSJH GothicBBB-Medium-83pv-RKSJ-H ... 5 CTTBC Copperplate-ThirtyThreeBC 5 CTTBC Copperplate-ThirtyTwoBC ... 5 NCSBI NewCaledonia-SemiBoldItalic 5 NCSBI NewCenturySchlbk-BoldItalic ... 4 AGCB AvantGarde-CondBold 4 AGCB AvantGarde-CondBook ... 4 BBBI BauerBodoni-BlackItalic 4 BBBI BauerBodoni-BoldItalic ... 4 HNBI HelveticaNeue-BlackItalic 4 HNBI HelveticaNeue-BoldItalic ... 3 AGB AGaramond-Bold 3 AGB AkzidenzGrotesk-Black 3 AGB AkzidenzGrotesk-Bold 3 AGB AvantGarde-Book ... 3 BBI BauerBodoni-Italic 3 BBI Berkeley-BlackItalic 3 BBI Berkeley-BoldItalic 3 BBI Berkeley-BookItalic 3 BBI Bodoni-BoldItalic 3 BBI Bodoni-BookItalic 3 BBI Bookman-BoldItalic ... 3 CBI Caxton-BoldItalic 3 CBI Caxton-BookItalic 3 CBI Centennial-BlackItalic 3 CBI Centennial-BoldItalic 3 CBI Century-BoldItalic 3 CBI Century-BookItalic 3 CBI Cheltenham-BoldItalic 3 CBI Cheltenham-BookItalic 3 CBI Clearface-BlackItalic 3 CBI Clearface-BoldItalic 3 CBI Cochin-BoldItalic 3 CBI Concorde-BoldItalic 3 CBI CooperBlack-Italic and so on. I sent e-mail to Adobe as President of TUG, but never got a reply to my question about their officially sanctioned abbrevs. Because the job will have to be done by hand, it is ESSENTIAL that the font supplier (i.e. Adobe) be the one to define the names; otherwise, we will end up with inconsistencies. Does anyone have the official abbrevs for ALL Adobe fonts? I have previous pointed out on this list that the X Window System Version 11 Release 4 has a generalized name scheme which permits users to request fonts by wildcard matching, as shown in these entries from my .twmwc window manager startup file: TitleFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" ResizeFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" MenuFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" IconFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*" IconManagerFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*" X11R4 handles the long names through a translation table stored in a file called fonts.dir that maps them to host file names: courBO08.snf -adobe-courier-bold-o-normal--11-80-100-100-m-60-iso8859-1 courBO10.snf -adobe-courier-bold-o-normal--14-100-100-100-m-90-iso8859-1 ... helvBO08.snf -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso8859-1 helvBO10.snf -adobe-helvetica-bold-o-normal--14-100-100-100-p-82-iso8859-1 helvBO12.snf -adobe-helvetica-bold-o-normal--17-120-100-100-p-92-iso8859-1 ... lutBS12.snf -b&h-lucidatypewriter-bold-r-normal-sans-17-120-100-100\ -m-100-so8859-1snf lutBS14.snf -b&h-lucidatypewriter-bold-r-normal-sans-20-140-100-100\ -m-120-s A reasonable question for discussion then is: (1) Should DVI drivers permit the use of full font names like Cheltenham-BoldItalic with the assumption that the DVI will be able to map this to a local file name? If ALL drivers did this, then the font naming and mapping problem for TeX users would go away. (2) Should DVI drivers permit wildcard matching as well? E.g. to get AvantGarde-BookOblique, \font\avgboxii = Ava*Ga*-Bo*Ob* at 12pt I already have code in the 3.0 DVI driver development that can handle the wildcard matching needed to support an extension of the font substitution file to support lines like this extract from the comments in the code: >> *.1499 -> *.1500 % replace 1499 mag fonts by 1500 fonts >> cm*.848 -> *.849 % replace cm 848 mag fonts by 849 mag >> amr10.* -> cmr10.* % replace mags of amr10 by cmr10 mags >> *.* -> cmtt10.* % replace missing fonts by cmtt10 fonts >> >> The following usage is NOT supported, because there is no code >> implemented yet to make partial substitutions. >> >> am*.* -> cm*.* % replace all am fonts by cm fonts I expect that it can already handle the matching of Ava*Ga*-Bo*Ob* with AvantGarde-BookOblique, or could be made to do so without much effort. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== ========================================================================= Date: Thu, 24 Jan 91 16:08:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Naming of Non-CM Fonts >I welcome the proposal from Berthold K.P. Horn and Teresa A. >Ehling on getting short standard names for Adobe fonts adopted >universally. Yes, the scheme by Karl Berry is cryptic, but it _is_ comprehensive. Let's not forget about the fact that Adobe PS is *not* the only typeface option in the world (thank goodness). And it's not a problem that's going to go away. I have sitting on my desk a nearly-new 386 PC running MS-DOS I get 8+3 for the filename. MS-DOS 5.0 is in beta test and will be released this summer. I'll _still_ get 8+3 for the filename. >I sent e-mail to Adobe as President of TUG, but never got a >reply to my question about their officially sanctioned >abbrevs. Because the job will have to be done by hand, it is >ESSENTIAL that the font supplier (i.e. Adobe) be the one to >define the names; otherwise, we will end up with >inconsistencies. Does anyone have the official abbrevs for ALL >Adobe fonts? But of course Adobe will want to call Adobe Times Roman TIMES and Compugraphic will want to call CG Times Roman TIMES and founder X will want to call their Times Roman TIMES. Trust me, relying on the vendor will not give you consistency across platforms. What would be more useful is a TUG registry of names. Then, we'll be able to cover MF-generated fonts as well as various external fonts. > have previous pointed out on this list that the X Window >ystem Version 11 Release 4 has a generalized name scheme which >permits users to request fonts by wildcard matching, as shown >in these entries from my .twmwc window manager startup file: >TitleFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" >ResizeFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" >MenuFont "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" >IconFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*" >IconManagerFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*" >X11R4 handles the long names through a translation table stored >in a file called fonts.dir that maps them to host file names: >courBO08.snf -adobe-courier-bold-o-normal--11-80-100-100-m-60-iso8859-1 >courBO10.snf -adobe-courier-bold-o-normal--14-100-100-100-m-90-iso8859-1 >... >helvBO08.snf -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso8859-1 >helvBO10.snf -adobe-helvetica-bold-o-normal--14-100-100-100-p-82-iso8859-1 >helvBO12.snf -adobe-helvetica-bold-o-normal--17-120-100-100-p-92-iso8859-1 >... >lutBS12.snf -b&h-lucidatypewriter-bold-r-normal-sans-17-120-100-100\ > -m-100-so8859-1snf >lutBS14.snf -b&h-lucidatypewriter-bold-r-normal-sans-20-140-100-100\ > -m-120-s Providing this functionality in the TeX environment will take an awful lot of work. >A reasonable question for discussion then is: >(1) Should DVI drivers permit the use of full font names like >Cheltenham-BoldItalic with the assumption that the DVI will be >able to map this to a local file name? If ALL drivers did this, >then the font naming and mapping problem for TeX users would go >away. How is the long name going to get into the DVI file? The issue here is essentially one of naming TFM files. Any sort of font mapping scheme where the user says \font\foo=b&h-lucidatypewriter-bold and gets lutbs14.tfm read in means that we need to modify every program that reads TFMs to take this into consideration. A partial list from my environment: - TeX - GFtoDVI - DVIcopy (resolves VF references) - DVIHPLJ - DVIPS and putting the code into TeX means that it's no longer TeX. Another thought: do you want to be the one to tell a user that they can't use PostScript fonts with TeX on machine A but they can on machine B even though both are running the same version of the same DVI driver? And also, diagnosing error messages is a lot nicer if the font name has some relation to a name of a file (or files) on the system. Mapping the short name to the internal name on the machine through a table is not just a good idea, that's a necessity. >(2) Should DVI drivers permit wildcard matching as well? >E.g. to get AvantGarde-BookOblique, >\font\avgboxii = Ava*Ga*-Bo*Ob* at 12pt No. See my comments on going from font names to file names. Plus, this again requires major modifications to TeX. -dh ========================================================================= Date: Thu, 24 Jan 91 16:13:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Extensions to TeX and the DVI standard For those of you who have been talking about making extensions to TeX within the context of making certain features more elegant, let me remind you that this group decided some time ago (two years or so, I believe) that we were working on a standard whose primary purpose is the correct processing of standard TeX82 DVI files with the norms determined by what TeX itself can do. Any feature which requires modifications to the TeX program, no matter how small, cannot be a part of the standard. The full features of the DVI standard should be available to the person sitting at a terminal with version 1.0 of TeX on their system and no source code. Yes, it's a limiting factor, but it's also a necessary factor. Talk about nicer font name support has its place but not, I'm afraid within the context of the DVI standards discussion. -dh ========================================================================= Date: Fri, 25 Jan 91 13:37:23 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Naming of Non-CM Fonts I fully agree with the notes of Don on this topic. Just one remark: > Mapping the short name to the internal name on the machine > through a table is not just a good idea, that's a necessity. And that's just because VF does not include any field which says: ``this is a build-in printer font with the internal name xyzzy''. With such a field we would have a unified standardized way of stating a font mapping from TeX font names to real font names. Grmpfh... If VF would have a font_special op code like GF or PK it would have been possible to standardize a coding. But it's not there. Grmpfh... Joachim ========================================================================= Date: Fri, 25 Jan 91 13:37:23 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Naming of Non-CM Fonts I fully agree with the notes of Don on this topic. Just one remark: > Mapping the short name to the internal name on the machine > through a table is not just a good idea, that's a necessity. And that's just because VF does not include any field which says: ``this is a build-in printer font with the internal name xyzzy''. With such a field we would have a unified standardized way of stating a font mapping from TeX font names to real font names. Grmpfh... If VF would have a font_special op code like GF or PK it would have been possible to standardize a coding. But it's not there. Grmpfh... Joachim ========================================================================= Date: Fri, 25 Jan 91 10:03:24 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jerry Leichter Subject: re: Extensions to TeX and the DVI standard For those of you who have been talking about making extensions to TeX within the context of making certain features more elegant, let me remind you that this group decided some time ago (two years or so, I believe) that we were working on a standard whose primary purpose is the correct processing of standard TeX82 DVI files with the norms determined by what TeX itself can do. Any feature which requires modifications to the TeX program, no matter how small, cannot be a part of the standard. The full features of the DVI standard should be available to the person sitting at a terminal with version 1.0 of TeX on their system and no source code. Yes, it's a limiting factor, but it's also a necessary factor. Talk about nicer font name support has its place but not, I'm afraid within the context of the DVI standards discussion. Sorry, I don't buy this argument. The issue being discussed here is INHERENT- LY a matter of extension: Whatever the TeXbook may say about fonts, in prac- tice TeX and the CM fonts have for years been inseparable. The availability of large numbers of non-CM fonts is a matter of fairly recent vintage. Someone using TeX V1.0, with macros and fonts consistent with what was avail- able at the time TeX V1.0 was the latest and greatest, could care less about the naming of AvantGardeBoldItalicSemicondensed: It's outside of the universe his software supports. ANY naming standard is outside that universe. If people were not interested in using non-CM fonts, or were those fonts not now available, we wouldn't be asking these questions. But they do and they are. We can decide not to decide - i.e., let every site pick its own naming conventions. That's the only decision really consistent with the DVI stan- ards discussion, but it's also a recipe for chaos. If you want to stand on the definition of the bounds of the discussion, then the discussion will simply move elsewhere (and in practice USEFUL DVI drivers will end up having to track whatever convention comes to be accepted). Having decided that SOME naming standard is necessary, the issue is then (a) live with the least common denominator and pack everything into 8 (or whatever) characters; or (b) try and come up with something with a future. While (b) does require changes to TeX, it requires them in exactly the sys- tem interface code that was intended to be changed. So what's the big deal? -- Jerry ========================================================================= Date: Fri, 25 Jan 91 07:47:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Extensions to TeX and the DVI standard -If people were not interested in using non-CM fonts, or were those fonts not --now available, we wouldn't be asking these questions. But they do and they a--re. We can decide not to decide - i.e., let every site pick its own naming -conventions. That's the only decision really consistent with the DVI stan- -ards discussion, but it's also a recipe for chaos. If you want to stand on -the definition of the bounds of the discussion, then the discussion will -simply move elsewhere (and in practice USEFUL DVI drivers will end up having -to track whatever convention comes to be accepted). - -Having decided that SOME naming standard is necessary, the issue is then -(a) live with the least common denominator and pack everything into 8 (or -whatever) characters; or (b) try and come up with something with a future. -While (b) does require changes to TeX, it requires them in exactly the sys- -tem interface code that was intended to be changed. So what's the big deal? - I apologize if I was unclear: Let me summarize my points: Discussion of font name standardization good, discussion of font name standardization throught TeX extensions bad. I sent a separate long note outlining my objections to the TeX extension approach. Consider this little deal: the primary platform with the 8-char limit is MS-DOS. The big 4 TeXs for the PC are all source-less. Those with source are horribly slow. Plus, it's not just TeX & the DVI driver which get changed but EVERY program which reads TFMs. I believe that we may even be implicitly asking for a mod to groff! We have a nearly-complete naming scheme already (Karl Berry's) which meets the 8-char limit and beginning a font name registry for extensions would not be a problem (it could be an extension of this committee's function). Of more importance in this realm is the issue of font character code mapping and how that relates to naming. The standard should tell people how to modify their drivers, not their TeXs. -dh ========================================================================= Date: Fri, 25 Jan 91 17:06:40 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: re: Extensions to TeX and the DVI standard Jerry Leichter wrote: > Having decided that SOME naming standard is necessary, the issue is then > (a) live with the least common denominator and pack everything into 8 (or > whatever) characters; or (b) try and come up with something with a future. > While (b) does require changes to TeX, it requires them in exactly the sys- > tem interface code that was intended to be changed. So what's the big deal? The big deal? Just that most TeX users (i.e., on PCs) don't have the source code for the TeX they are using. Those people may not change the system interface code! We are not only talking of privileged users. I'm sure that now a con argument comes: Then they shall buy an upgrade. Well, how often are they in the position that they may spend the money for an update of a site license? Therefore I prefer method (a). Please note that this is not because I'm a DOS user. I usually work on a UNIX system. But what do you do with file names on UNIX System V (14 chars!!), MVS, VM/CMS, BS2000, TOS, etc? I'm used to work on more than 5 operating systems in parallel -- I wish all of you good luck in establishing a common naming standard; transparent, implemented, and available to all systems where TeX is running. Joachim ========================================================================= Date: Wed, 30 Jan 91 16:16:38 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: ammendment 11 is obsolete Don Hosek sent out three official ammendments which I phrased in November 1990. The ammendment 11 (``always issue a warning if fonts are missing'') is obsolete. The topic was covered in the change from standard 0.04 to 0.04a with the substition of ! If a font is missing the processor must continue processing and deal with the missing font in one of three ways: with ! If a font is missing the processor must continue processing and, ! after issuing an appropriate warning message, deal with the missing font in one of three ways: (exclamation marks show the changes). Please note that I had already sent a remark concerning this in December: > Ammendments 09 (clarify phrases in sections 2.6.2, 2.6.3, and 4.4) > and 12 (always issue a warning if fonts are missing) got obsolete > with the new draft 0.04a. They are to be discarded. Joachim Schrod ========================================================================= Date: Wed, 30 Jan 91 16:16:38 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: ammendment 11 is obsolete Don Hosek sent out three official ammendments which I phrased in November 1990. The ammendment 11 (``always issue a warning if fonts are missing'') is obsolete. The topic was covered in the change from standard 0.04 to 0.04a with the substition of ! If a font is missing the processor must continue processing and deal with the missing font in one of three ways: with ! If a font is missing the processor must continue processing and, ! after issuing an appropriate warning message, deal with the missing font in one of three ways: (exclamation marks show the changes). Please note that I had already sent a remark concerning this in December: > Ammendments 09 (clarify phrases in sections 2.6.2, 2.6.3, and 4.4) > and 12 (always issue a warning if fonts are missing) got obsolete > with the new draft 0.04a. They are to be discarded. Joachim Schrod ========================================================================= Date: Wed, 30 Jan 91 19:32:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: ammendment 11 is obsolete Amendment 11 has been removed as per Joachim's request. -dh