========================================================================= ========================================================================= Date: Mon, 21 Oct 1991 13:00:44 +0100 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Missing fonts (impossible to implement the standard?) Section 4.4 (`Missing fonts') reads > If a font is missing the \DVI{} processor must continue processing and, > [...] deal with the missing font in one of three ways: > > 1. Insert black rectangles of the size of the character given in > the {\tt TFM} file for the font. > 2. Insert black rectangles of the size of the character given in > the {\tt TFM} file for the font. > 3. Print the characters from that font at a different size or > from another font at the same size. What should be done if - a font isn't available at any size and no font is available at the size of that font (item 3 cannot be applied) - and there is no TFM file (items 1 and 2 cannot be applied)? Aborting violates section 4.4. Continuing and omitting characters violates section 2.6.2 (`Changes in position...'). Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ========================================================================= Date: Mon, 21 Oct 1991 17:58:25 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Missing fonts (impossible to implement the standard?) In-Reply-To: <9110211645.AA02536@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Eberhard Mattes" at Oct 21, 91 1:00 pm Eberhard Mattes wrote on the topic of missing fonts: > > What should be done if > > - a font isn't available at any size and no font is available at > the size of that font (item 3 cannot be applied) > > - and there is no TFM file (items 1 and 2 cannot be applied)? > > Aborting violates section 4.4. > Continuing and omitting characters violates section 2.6.2 (`Changes in > position...'). From draft 0.05a: \begin{standard} If a font is missing the \DVI{} processor must continue processing and, after issuing an appropriate warning message, deal with the missing font in one of three ways: \begin{enumerate} \item Insert appropriate white space where characters of the font would appear. \item Insert black rectangles of the size of the character given in the {\tt TFM} file for the font. \item Print the characters from that font at a different size or from another font at the same size. \end{enumerate} >> If methods 1 or 2 are used and the processor is unable to determine >> size information for the font in question, then the processor may >> simply ignore any character setting command >> that occur while the current font is that font. Under no circumstances should a missing font cause a fatal error. \end{standard} The marked paragraph should be changed into: If the processor is unable to determine size information [...] (this discarding ``If methods 1 or 2...''). I consider this as a small change (i.e., the correction of an oversight) which does not need an ammendment. If anybody on this list has an other opinion, he or she must contact me (or post it to the list). On the other hand, it might be pointed out that the sentence ``Whenever the \DVI{} processor encounters an instruction that changes the current position, it must update $h$ and $v$. If the change in position is due to a command which sets a character, the processor adds the horizontal escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $\it hh$.'' [section 2.5.2 -- not 2.6.2!!] is not true in such a case. Any opinions? -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Secretary of TUG DVI standards committee ========================================================================= Date: Mon, 21 Oct 1991 12:20:13 -0500 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Stephan Bechtolsheim Subject: Missing fonts (impossible to implement the standard?) In-Reply-To: Joachim Schrod's message of Mon, 21 Oct 1991 17:58:25 MEZ <199110211718.AA29613@arthur.cs.purdue.edu> Make a quick decision and then take the "don't care attitude" It's not really an interesting aspect to deal with the missing font issue. A document printed with a missing font (whatever is done to fix it up) is useless as far as final output is concerned. StvB ========================================================================= Date: Mon, 21 Oct 1991 11:45:44 MDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Missing font characters I believe that the DVI driver must continue processing in the absence of a font file (including .tfm); where the wording in the draft DVI standard conflicts with this goal, the wording needs to be changed. Eberhard and Joachim have identified two such places, and offered a change for one. Perhaps 2.5.2 could be changed to read (==> marks the addition): ``Whenever the \DVI{} processor encounters an instruction that changes the current position, it must update $h$ and $v$. If the change in position is due to a command which sets a character, the processor adds the horizontal escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $\it hh$. ==> If the font file is unavailable, the update may be suppressed as ==> long as a warning message is issued.'' (As a parenthetical remark, it may be unwise to specify PK or GF file here, and use instead ``font file''; consider a driver dealing with device-resident fonts, such as PostScript, for which metrics come from different kinds of files than PK or GF). ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== ========================================================================= Date: Mon, 21 Oct 1991 19:03:55 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Missing font characters In-Reply-To: <9110211758.AA02886@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Nelson H. F. Beebe" at Oct 21, 91 11:45 am Nelson Beebe wrote: > (As a parenthetical remark, it may be unwise to specify PK or GF file > here, and use instead ``font file''; consider a driver dealing with > device-resident fonts, such as PostScript, for which metrics come from > different kinds of files than PK or GF). This is a general problem in itself and is on my list of open problems: Shall the standard really **require** the support of PK files? What if a non-bitmap device is used? Then PK files are of no use anyway. What if a driver supplies a utility which converts a PK file into an internal format but does not use PK files itself? (Note, this might be the case in drivers for phototypesetters, e.g., for the Hell ones [Digiset]). -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Secretary of TUG DVI standards committee ========================================================================= Date: Tue, 22 Oct 1991 12:19:00 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: Re: Missing font characters Nelson suggested adding ==> If the font file is unavailable, the update may be suppressed as ==> long as a warning message is issued.'' I think all warnings should be suppressable. ========================================================================= Date: Thu, 24 Oct 1991 09:40:14 +0100 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Missing fonts In-Reply-To: Karl Berry's message of Tue, 22 Oct 1991 12:19:00 EDT <9110221624.AA13811@azu.informatik.uni-stuttgart.de> Nelson suggested adding ==> If the font file is unavailable, the update may be suppressed as ==> long as a warning message is issued.'' MUST the warning be omitted if only put_char is used with characters from a missing font? I would prefer a warning for a missing font without a warning for missing cursor movements due to a missing font. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ========================================================================= Date: Thu, 24 Oct 1991 11:12:20 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Missing fonts In-Reply-To: <9110240851.AA05491@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Eberhard Mattes" at Oct 24, 91 9:40 am Eberhard Mattes wrote: > > Nelson suggested adding > > ==> If the font file is unavailable, the update may be suppressed as > ==> long as a warning message is issued.'' > > MUST the warning be omitted if only put_char is used with characters > from a missing font? I would prefer a warning for a missing font > without a warning for missing cursor movements due to a missing font. I agree with Eberhard. The latter is a followup error of the first. Only the cause should be flagged, not the symptom. Any more voices on Karl's opinion that all warnings should be suppressable? (I must tell a story in this context: A version of TeXtures used to scale the bitmaps of fonts when they were not available -- but without telling the user of this action. Users that care for typographic quality afterwards sat down and checked the final output of their documents for such occasions. This showed me how urgent warnings are needed... [Disclaimer: I don't use TeXtures and have never used it seriously. This `feature' was told me by other users, I tried it afterwards, but have no deep first-hand experience. I don't know if the behaviour of TeXtures has changed in the mean time.]) -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ========================================================================= Date: Thu, 24 Oct 1991 14:26:00 N Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Konrad Bernloehr (BERN@DHDMPI50.bitnet)" Subject: Re: Missing fonts I think that, when talking about 'missing fonts', one should distinguish between 'missing character bitmaps' and 'missing character metrics'. It may well happen that no character bitmaps (e.g. PK file) are found for a font but the metrics (usually from TFM file) are available. For this reason, 'missing font' and 'no cursor movement due to missing font' warnings should be issued separately. The second is not really a follow-up error of the first (as Eberhard Mattes suggested). Concerning the suppression of warnings my opinion is that all warnings should have a level indicating how serious they are. The user may then decide how much information he/she wants to get. This concept is used by many compilers. Assume that level 0 are fatal error messages, level 1 are serious warnings, and level 3 are informational messages. Only the level 0 messages should be non-suppressable. The 'missing character bitmaps' and 'missing character metrics' should be at level 1, while the 'scaling of character bitmaps' (mentioned by Eberhard Mattes) should be rather at level 2 or 3. The question then is what should be the default warning level. I think that depends on the output device. For output to a photo typesetter certainly more information seems appropriate than for previewing with a single screen, where most users probably don't like to get many unimportant warnings (like 'bitmap scaled'). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Konrad Bernl\"ohr (bern@dhdmpi5v.bitnet) ========================================================================= Date: Thu, 24 Oct 1991 15:20:51 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Missing fonts In-Reply-To: <9110241334.AA05994@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Konrad Bernloehr" at Oct 24, 91 2:26 pm You wrote: > > I think that, when talking about 'missing fonts', one should distinguish > between 'missing character bitmaps' and 'missing character metrics'. > It may well happen that no character bitmaps (e.g. PK file) are found > for a font but the metrics (usually from TFM file) are available. > For this reason, 'missing font' and 'no cursor movement due to missing > font' warnings should be issued separately. The second is not really > a follow-up error of the first (as Eberhard Mattes suggested). Sorry, but if only a TFM file is found, the font is still missing. As you said, a metric is not the same as a font. I just checked the standards text -- each time where font is used it either refers to the font specification in the DVI file or explicitely to PK or GF files. When TFM is mentioned such expressions as `TFM file for the font' appear. Of course, a well written driver will issue different error messages in the two cases, (eg, `Font xyzzy missing, using TFM file for spacing' resp. `Font xyzzy missing, characters will be discarded.') But it should not output a whole bunch of error messages, this is not user-friendly. Please note that I assume that a font is only loaded if it is really needed; ie, if a postamble names a font but this font is not used on the rendered pages there should not happen anything at all. (Such a strategy is easy to implement and after all, the driver will be much faster...) I like the idea with the warning levels (especially as we use such a level scheme already in our drivers...). I propose that there will be a tier on such convenience stuff, it has not much to do with the effective basic functionality of a DVI processor. (Such a tier on user interface functionality might also name strategies for page selection etc.) -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ========================================================================= Date: Thu, 24 Oct 1991 14:51:12 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: Re: Missing fonts I certainly agree that at least some warnings should be enable by default; it's up to the DVI processor writer to do a good job choosing which warnings should be on by default. The thing I do feel strongly about is that all warnings should be suppressable. Very often, a warning message that happens about one font (say) will also happen for every other font in the document. This volume of information wuold obscure any useful diagnostic information. (Many compilers have this problem.) As for levels of warnings, I think it would be very hard for a processor writer to assign in advance what level a particular warning would be. I think the assignment would be somewhat arbitrary, at least in some cases. It may be useful to users if there was a coherent scheme behind each level, though. (I'm sure that's what the program authors would strive for, but wqhat's coherent to one person is not always coherent to another.) But even if the warnings are grouped into levels, I think the warnings should be individually suppressable. Otherwise, inevitably, it seems to me, some user will want to suppress all warning X's for some reason, but not warning Y's, and X and Y happen to be in the same class.