========================================================================= Date: Thu, 7 Nov 1991 21:03:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Warnings Regarding the issue of supressible warnings, I must say that I strongly oppose it. To understand why, consider the following two questions: - Should error messages be supressable? - What distinguishes a warning from an error message? I think that most people agree that error messages should always be printed (or be supressed only with some difficulty). With this thought in mind, consider is it really a warning or an error that a font is missing? It's fairly important that the user know that his output is going to appear incorrectly (in fact, I'm almost inclined to suggest that when useful/possible that a warning be printed on the output device's display as well). Turning off informational messages (a la the page/file displays of Tom Rokicki's dvips) seems reasonable. Supressing important information like missing font errors/warnings is omitting important information. -dh ========================================================================= Date: Fri, 8 Nov 1991 11:02:56 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Ed Garay (u12570@uicvm.uic.edu)" Subject: Re: Warnings In-Reply-To: Message of Thu, 7 Nov 1991 21:03:00 PST from Sorry for barging in, but I think it would be nice if the TeX user or installation is given the option of setting the level of warning/error messages to be displayed. Fatal error messages should probably always be displayed, but posting less severe error messages, warnings and informational messages should be left to the user or TeX maintainer. Consider a situation where you already know that you are missing a font, but you keep modifying your TeX file and printing it to get closer to finishing it -- you'll take care of the missing font later. A MSGLEVEL option of 0, for example, would suppress all messages, 4 displays some, 8 displays some more (of less severity), msglevel 12 produces warnings as well, and so on. Define whatever msglevel scale you think it is appropriate, set the msglevel default to display all error messages and warnings, if you will, but please give the user the option of controlling the amount of information to display. --- Ed On Thu, 7 Nov 1991 21:03:00 PST Don Hosek said: >Regarding the issue of supressible warnings, I must say that I >strongly oppose it. To understand why, consider the following two >questions: > >- Should error messages be supressable? > >- What distinguishes a warning from an error message? > >I think that most people agree that error messages should always >be printed (or be supressed only with some difficulty). With this >thought in mind, consider is it really a warning or an error that >a font is missing? It's fairly important that the user know that >his output is going to appear incorrectly (in fact, I'm almost >inclined to suggest that when useful/possible that a warning be >printed on the output device's display as well). > >Turning off informational messages (a la the page/file displays >of Tom Rokicki's dvips) seems reasonable. Supressing important >information like missing font errors/warnings is omitting >important information. > >-dh ========================================================================= Date: Fri, 8 Nov 1991 12:54:26 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: Re: Warnings Sometimes I am well aware a font is going to be missing, and I don't care, and I have dozens of these missing fonts, and I want to get whatever other warnings there are, which I would lose amongst all the verbiage. If messages are individually or close to individually suppressable, I don't see that Don's objections still hold. I.e., if I say -no-font-warnings or whatever, obviously I don't want font warnings. Why not provide this? ========================================================================= Date: Fri, 8 Nov 1991 13:15:11 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa Subject: Suppressing warnings In-Reply-To: Don Hosek's message of Thu, 7 Nov 1991 21:03:00 PST <9111080516.AA14913@orion.arc.nasa.gov> My view is that the dvi standards committee could usefully determine whether a particular circumstance constitutes an error or not. For instance, if a font could not be found. The committe could also usefully determine what action is to be taken in case of an error or warning (e.g., what value does the application return to the shell when it terminates?). In any event, a conforming application (e.g., dvi translator) should not be constrained to inevitably present messages of any class. Thus one could write an application which has the ability to suppress or present messages in a way that the user can configure at will. This application would be conformant. One could also write an application which presents error messages, and is not configurable at all. This application would also be conformant. Note that TeX itself has no warnings, but does have errors, and some of these are fatal. (Debate this statement!) There is no standard among its implementors as to the value returned by TeX to the OS when it terminates. The flaw in some early dvi translators has been that the failure to find a font was treated as a fatal error. The programmer who wrote that code should justifiably blush, and it is good that the level-0 standard addresses this problem. But there is no point in constraining the configurability of an application. I know that software that has limited configurability will be rejected by some of my clients (commercial vendors, take note). Printing a warning message on the output device's display is an option, certainly. There is a precedent for this, in that a PostScript imagesetter can be configured to print an error summary at the end of a job (this appears on a _separate_ page of output). This course is especially useful in those cases (prevalent outside of the Macintosh domain) where the error messages reported by the RIP are not passed back to the user by the printing interface. Printing a warning message in the middle of the user's page is also an option, but one that can only rarely be justified. This has been the case where the stakes are high, as in a classified document in which the page classification is known to be incorrect, say. But oonce again, an application which printed such a message, without the ability to suppress (not supress) that message, would simply be rejected in the marketplace. In short, when designing software, recognize the unique needs of your users. And in promulgating a standard, do not outlaw enhancments for which there exists a legitimate need. Arthur Ogawa Internet: ogawa@orion.arc.nasa.gov Ph: 1/415/691-1126 TeX consultant AppleLink: ogawa FAX:1/415/962-1969 ========================================================================= Date: Fri, 8 Nov 1991 14:38:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: TFM directories -Date: Thu, 24 Oct 91 15:48:43 MDT -From: "Nelson H. F. Beebe" -Wayne G. Sullivan writes ->> ... ->> The reason in one case why TEXFONTS was not used for the TFM directory is ->> that widely distributed DVI drivers use TEXFONTS for FONTS. Though it ->> might have been an unwise original choice to use TEXFONTS to specify the ->> directory for TFMs, its use for another purpose in the DVI driver programs ->> is even more unfortunate. Has this been corrected? Is it safe now to use ->> TEXFONTS to specify the TFM directory (directories)? ->> ... -The reason is that at Stanford, Don Knuth chose to store the bitmaps -and metrics in the same directory, which is exactly how they end up -when you run METAFONT. With long file names, there was no problem in -having cmr10.tfm, cmr10.300gf, cmr10.329gf, ... all in the same place. -VAX VMS systems before version 4.0, PC DOS, and others with short file -name requirements led to implementors moving the magnification out of -the filename into the directory name, e.g. 300\cmr10.gf, 329\cmr10.gf, -..., and in {\em those} environments, it makes sense to put the .tfm -files in a separate directory too, since there is then no good reason -why they should live in the same file directory as a bitmap at a -ä =Èÿparticular size. -I have seen TeX implementations (e.g. that of Personal TeX, Inc) that -use separate TEXFONTS and TEXTFMS search paths. -Few drivers ever use .tfm files, so they question hasn't come up for -them as often. -My 2.10 drivers did not read .tfm files, but those in the 3.0 -development do; they find them in the TEXFONTS search path. If there -is strong feeling in the implementors community that drivers that read -.tfm files should support a separate TEXTFMS path, I can easily do -that, since 3.0 sources have not yet been released to anyone, and only -about 3 or 4 lines of code need to be changed. I'd do it in such a -way that if lookup failed on TEXTFMS, I'd fall back to TEXFONTS anyway. -In my 3.0 drivers, .tfm files are only consulted when bitmap -representations cannot be found, so efficiency of file lookup is -definitely not an issue; it might be in a PostScript driver that -needed .afm files for use with printer-resident fonts. Raster and metric fonts should be searched for using independent search paths. The names of these paths should be configurable (ideally without recompilation of the driver). On most/all TeX distributions which I've come across, PKs and TFMs live in separate directories. The exact logical name that points to them can vary, however, depending on the implementation. e.g., VMS uses TEX_FONTS (sometimes TEX_FONT_METRICS and incorrectly, TEX$FONTS). on DOS I've seen TEXFONTS, TEXTFMS and TEXTFM. (btw, for VMS developers, the change files for TeX and MF provide one good way to configure these things for VMS. -dh ========================================================================= Date: Sat, 9 Nov 1991 12:10:34 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: Re: TFM directories I disagree about searching for TFM's and rasters along independent paths. I think TEXFONTS shoudl be searched for both (obviously, since that's what I've implemented). The reason is that some sites -- mine, at least -- keep font files by typeface, not format. I have the tfm's and the pk's in the same directory. (I know this isn't a general solution, but I don't have any devices which would generate conflicting raster files, so this is the most convenient thing for me to do.) I don't see any reason why I should have to set two search paths instead of one. In fact, I think VF's should also be searched for using TEXFONTS. This is not to say there shouldn't be other paths which are only searched for one or the other. Here (again) is the algorithm web2c (and xdvi, and dvips, at least in the enxt release) uses: For TFMs: TEXFONTS. For PKs: PKFONTS, then TEXFONTS. For VFs: VFFONTS, then TEXFONTS. (forgetting about subdirectory searching)