========================================================================= Date: Fri, 22 Mar 91 11:38:44 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: bbeeton Subject: suggestion for future reference i've just received the following inquiry: I wonder if you could let me know the method used in TUGboat to print in landscape mode on a page with headers or footers in portrait mode, as for instance with the output device tables. We have been able to do this using \TeX's {\tt special} command on an LN03+, but it has now become necessary to get a new printer and so far we have not been able to find a combination of printer and driver which will do this. tugboat pages of this form are still pasted up by hand (a fact which we neglected to mention in the "production notes, but which should clearly be added there), so i was unable to help the person inquiring. however, i believe that the driver standards committee at some point discussed how to identify features of a particular printer or driver that exceed the level 0 standard. this is a useful feature that should be identified, in my opinion, and if you ever do get around to devising a features checklist, i hope you will include it. -- bb ------- ========================================================================= Date: Mon, 25 Mar 91 13:03:14 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: suggestion for future reference > [...] if you ever do get around to > devising a features checklist, i hope you will include it. I've started to write such a list but had to stop because of other (for me more important) work. I'll post it in April for further discussion. (The landscape-within-a-portrait-page feature is already included :-) Joachim BTW: Don, what's the state of voting for ammendments 09 and 10? I haven't received any information. ========================================================================= Date: Mon, 25 Mar 91 08:01:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendments 9 & 10 have passed |Amendment Number | | | | | | |0000|0000|0111|1111|1112|2222 |1234|5678|9012|3456|7890|1234 --------------------------+----+----+----+----+----+----- Nelson Beebe |YNNN|YYYY|XXo | | | Bart Childs |YYYY|yYYN|YYo | | | Adrian Clark |ZZZZ|YNNY|XXo | | | Andrew Dobrowlowski |ZZZZ|ZZZZ|YYo | | | Bernard Gaulle |YNNN|YYYN|YYo | | | John Gourlay |YNNN|YYAA|XXo | | | Robert McGaffey |XXXX|XXXX|XXo | | | Tom Rokicki |YNNN|YYYN|YYy | | | Jan Michael Rynning |nYyy|yYYY|XXo | | | Joachim Schrod |YYNN|YYYY|XXo | | | Ralph Youngen |XXXX|XXXX|XXo | | | --------------------------+----+----+----+----+----+----- Pass/Fail: |PfFF|PPPP|YYW | | | Legend: ------- A Abstain F Failed f failed with chair's tie-breaker N No P Passed p passed with chair's tie-breaker Y Yes W Withdrawn X No vote received Z Not on committee when amendment submitted n "no" Vote received after amendment decided: included "for the record" y "yes" Vote received after amendment decided: included "for the record" o Amendment withdrawn before vote received Amendment 1: Change margin of error tolerance (S4.3.2) Amendment 2: Change padding to end of DVI files (appendix A) Amendment 3: Change padding to end of GF files (appendix B) Amendment 4: Change padding to end of PK files (appendix C) Amendment 5: Change to wording of minimum stack depth (S2.5) Amendment 6: DVI limits only for devices which may support it (S2) Amendment 7: Change to definition of limits for maxdrift (App E) Amendment 8: Change to maxdrift value (App E) Amendment 9: Definition of round() in section 2.6.2 Amendment 10: Change of max_drift correction ========================================================================= Date: Mon, 25 Mar 91 17:53:47 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Amendments 9 & 10 have passed The new complete standards text for level 0 will be installed on the Heidelberg Listserver by tomorrow evening. (To get it send a mail with the line GET DVISTD0 TEX DRIVER to listserv@dhdurz1.bitnet.) It will also be forwarded to Don for the ymir server. Other interested server administrators should get in contact with me. -- Joachim =========================================================================== Joachim Schrod Computer Science Department Technical University of Darmstadt, Germany ========================================================================= Date: Mon, 25 Mar 91 19:24:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Amendments 9 & 10 have passed Actually I'd already updated the text at ymir. send the command send [tex.dvi-standard]level0-draft.tex to mailserv@ymir.claremont.edu to get a copy. I imagine that it would be largely in harmony with Joachim's copy (there might be a few odd diffs in some formatting). -dh ========================================================================= Date: Thu, 28 Mar 91 16:34:26 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: comments on dvi standard 0.04c I have two substantive comments about the dvi standard .04c, and lots of editorial ones. But first: * There is a minor TeX error, namely, a missing $: *************** *** 293,295 **** After any horizontal movement, a final check is made as to ! whether ${\it dist} > {\it max\_drift} with ${\it dist}$ is defined as $\abs({\it hh}-\round(Kh))$. If it is, then ${\it hh}$ --- 269,271 ---- After any horizontal movement, a final check is made as to ! whether ${\it dist} > {\it max\_drift}$ with ${\it dist}$ is defined as $\abs({\it hh}-\round(Kh))$. If it is, then ${\it hh}$ Here are the two substantive comments: * In section 2.6.4 (Objects off the page), the standard requires the processor to either omit or clip printable objects that would lie partially off the physical page. The explanation says it is up to the processor writer to handle this case correctly, s/he can't rely on the device. I don't believe this is possible to do for all devices. I know the most about PostScript devices; there, the user can do arbitrary things at arbitrary times to the coordinate system, so that it is impossible to tell whether or not an object will be off the page until print time. Furthermore, the physical page, which I take to mean the piece of paper, might be something other than what the driver or DVI file expects (i.e., the user might put in legal-sized paper to print a document that was formatted for 8.5x11 stock.) In that case, the processor obviously can't be expected to read the user's mind! What do we gain by requiring DVI-processor to do this (assuming it's possible to do)? Speaking as a user, I know the characteristics of my output devices, and if I put things off the page, I don't expect the driver to somehow magically get rid of them. In fact, if I inadvertently put something partially off the page, and my device is happy to ignore the extra marks, I want to see that the object went off the edge -- but with this clause, the driver writer might have detected that the object goes off the edge, and omitted it entirely. * In section 3 (Configuration), the standard says that ``such things as the location and naming scheme of fonts, default paper size, etc.'' must be configurable about recompilation. If I was writing a driver, I would have no idea what ``etc.'' meant, except ``make as many things configurable as possible''. Here are the editorial comments. I would be glad to actually make these changes and then submit a diff for inspection, if that's easier for you all to deal with. * In some places, the standard refers to ``DVI processors''; in others, to ``processors''; in others, to ``DVI-reading programs''; and in still others, to ``drivers''. As a matter of style, I think one term should be used; a sentence could be added at the end of the first paragraph of section 1: The standard hereafter calls such DVI-processing programs ``processors''. [or whatever term] * The explanation in section 2 (The DVI file) starts with `Because'. When I first read it, I wasn't sure what it was whose reason was being given. How about starting that sentence with `The exception above is necessary because...'? * The explanation in Section 2.1 (DVI commands) uses a `:' where it should use a `;': ``conditions outside those enumerated below: despite this,'' should be ``...below; despite this,...''. Also, the `Note that' at the beginning of the explanation is redundant. (This is also true of the `note that's in sections 2.2.1 and 2.2.2.) Finally, there should be a comma after ``put4''. * The title of Section 2.2.1 refers to a ``DVI font''. Shouldn't this just be ``font''? Font definitions are't part of the DVI file, after all. The phrase is used in section 2.7.2 (Distinct DVI fonts), also. * In section 2.2.3 (Number of DVI characters), what is the difference between a ``DVI character'' and a ``character''? The former term implies there is something special going on. Perhaps ``characters from fonts'' would be clearer? (The phrase is used in the title of section 2.2.2, also.) * Section 2.8 (Specials) is unclear as it stands. The second sentence says non-standard specials ``should'' be flagged; `should' should probably be `must' here. The next sentence says the driver ``must'' issue a warning if it ignores specials, instead of when it encounters a special that it ignores. Also, the term ``special'' is never defined. Also, the first sentence `requires no support for specials' isn't quite right -- `requires support for no specials' I think is closer to the intent (the driver still has to recognize the opcodes, for example). And `Level 0 Standard' is redundant in this context. Here is my stab at revised wording with, I think, the same meaning: 2.8 Specials A `special' is the parameter to an {\it xxx} command (see Appendix~\ref{dvi-format}). Such specials usually, but not always, consist of printable characters. This standard does not define the meaning of any specials. When the processor encounters a special whose meaning is not officially defined, or when a special that it does not recognize, it must issue a warning message unless the user has inhibited such warnings. * I think the first sentence of section 4.2 (The scaling number) could be improved to ``...font are combined into a scaling number in one of two ways:''. * In section 4.3.1 (Minimum set of magnifications), ``At the minimum'' is redundant. ========================================================================= Date: Fri, 29 Mar 91 13:34:03 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: comments on dvi standard 0.04c I will include the comments of Karl in the standard. One comment: I have just now ordered the version of the standard at ymir since in my version there is no TeX error. I will make the new definitive 0.04c version and a diff to the ymir version available after Eastern. -- Joachim ========================================================================= Date: Fri, 29 Mar 91 15:43:17 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Amendments 9 & 10 have passed In-Reply-To: Don Hosek's message of Mon, 25 Mar 91 19:24:00 PST <9103260431.AA20336@june.cs.washington.edu> Let me ask again. Does the present language make it clear that the dimensions (as adjusted to resolution) of the TFM box do not limit the dimensions of the glyph. It seems to me that the case of kerned areas past the right and left (TFM) side-bearings are accounted for, but I am not sure that kerned areas above and below the TFM height and depth are clearly allowed. I know of at least one commercially available driver which bombs on characters with kerns outside the TFM height and depth. I do not think it should do that. (Note, I am using kern in the traditional sense, to mean an extension of the face beyond the rectangular body of the type, like the overhang in the terminal blob of f, but up and down, rather than to the right and left.) 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: Fri, 29 Mar 91 18:43:10 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: Amendments 9 & 10 have passed In-Reply-To: Your message of Fri, 29 Mar 91 15:43:17 -0800 One quick comment on font files being less that honest about character extents: Some printers, such as the very popular HP LaserJet printers, require that a font header be sent to the printer declaring the true extents of the largest characters in the font (i.e. a font bounding box). Presumably, this information is used in bitmap memory allocation decisions. In any event, its impact on a DVI driver is this: the driver must read each character in the font, extract the bitmap, and examine it to find the true extents, so as to determine the font bounding box. In the case of my drivers, this is not done: the extents from the font file (xoffp, yoffp, wp, hp) are believed to be true, and are used to compute the font bounding box and baseline. The only character bitmaps ever unpacked are those that are actually requested by set_char commands in the .dvi file. Thus, if a font comes along where characters extend beyond the (xoffp, yoffp, wp, hp) values, the font header that is sent to the printer will be wrong, and an error may occur. I'm therefore inclined to want to have honest dimensions specified for (xoffp, yoffp, wp, hp), since otherwise, code changes in virtually all DVI drivers may be needed. ======================================================================== 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: Fri, 29 Mar 91 17:54:12 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Re: Amendments 9 & 10 have passed I see no reason that the envelope for the glyph should ever lie. I just don't want it to be forced to reflect the dimensions in the tfm file. Doesn't metafont always provide information about the maximum excursion from 0.0 for each character? ========================================================================= Date: Fri, 29 Mar 91 18:58:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Amendments 9 & 10 have passed -One quick comment on font files being less that honest about character -extents: -Some printers, such as the very popular HP LaserJet printers, require -that a font header be sent to the printer declaring the true extents -of the largest characters in the font (i.e. a font bounding box). -Presumably, this information is used in bitmap memory allocation -decisions. -In any event, its impact on a DVI driver is this: the driver must read -each character in the font, extract the bitmap, and examine it to find -the true extents, so as to determine the font bounding box. -In the case of my drivers, this is not done: the extents from the font -file (xoffp, yoffp, wp, hp) are believed to be true, and are used to -compute the font bounding box and baseline. The only character -bitmaps ever unpacked are those that are actually requested by -set_char commands in the .dvi file. Thus, if a font comes along where -characters extend beyond the (xoffp, yoffp, wp, hp) values, the font -header that is sent to the printer will be wrong, and an error may -occur. This isn't the problem. The problem is with a character where the TFM dimensions are not correct; you're talking about the font bounding box given in the PK/GF file which should always be correct unless it comes from some odd source (and presumably can be fixed by a PKtoGF/GFtoPK cycle). On the other hand, it is perfectly reasonable for the character to extend beyond TFM dimensions. `f' in many fonts is an example of this. Other cases include many math extension characters. -I'm therefore inclined to want to have honest dimensions specified for -(xoffp, yoffp, wp, hp), since otherwise, code changes in virtually all -DVI drivers may be needed. I hate to say this, but that's a lousy reason to oppose a change. If something is handled incorrectly, it should be fixed. From your description, either you are thinking the characters are extending beyond a different boundary than they are or your HP driver works incorrectly. I believe it's the former. -dh ========================================================================= Date: Fri, 29 Mar 91 22:42:01 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: vertical kerning again Just to clarify my concern again --- The driver standard makes it quite clear that kerns to right and left are to be accommodated; my concern is that kerns up and down be accommodated also. There might seem to be a problem in this, in that GF format gives min m = -8, max m = 34 min n = -8, max n = 33 values in the postamble, and PK suppresses this information, though pktogf is capable of restoring it, presumably because it IS the postamble, and all characters have already been read. However this doesn't seem to affect Nelson's drivers, since the per-character pixel offsets remain honest. No reason for them not to be. But what I suspect may be happening is some drivers is that the array space for the vertical dimension of a bitmap is arbitrarily being set as the number of pixels per em (i.e. 42 pixels for 10-point at 300dpi) and if the character happens to have more than that above the baseline, the driver fails. There must be an accommodation below the baseline, because the cmex font would always fail if there weren't. Anyway, let me assure one and all that the only concern is to keep the real dimensions in whole pixels as expressed in the header for each character independent of the calculated height that might be derived by applying |true_conv| to the TFM height. Here for example is the PK header for K with its proper height (the font is cmr10). Height = 28 Width = 28 X-offset = -2 Y-offset = 27 and here are the TFM dimensions for that character (CHARACTER C K (CHARWD R 0.777781) (CHARHT R 0.683332) ) but here is the PK header for K with .2 of its proper height Height = 28 Width = 28 X-offset = -2 Y-offset = 27 and here are the TFM dimensions for that stunted character. (CHARACTER C K (CHARWD R 0.777781) (CHARHT R 0.170833) ) To do that, I set up beginchar with .2cap_height# and then used an assignment h:=5h; to get the right value for h before any control points were established. As you see, the PK header is unaltered, but the TFM heights are radically different. That is exactly what is needed, and it ought not to make trouble for Nelson's driver at all if I understand him correctly. (Incidentally, you have to be a bit cleverer if you want a zero-height character, but you can still make it work.) 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: Sat, 30 Mar 91 21:28:38 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Arthur Ogawa Subject: Amendments 9 & 10 have passed In-Reply-To: Don Hosek's message of Fri, 29 Mar 91 18:58:00 PST <9103300314.AA20286@orion.arc.nasa.gov> > I hate to say this, but that's a lousy reason to oppose a change. What I like about you, Don, is that you don't mince words :-) Arthur Ogawa Internet: ogawa@orion.arc.nasa.gov Ph: 1/415/691-1126 TeX consultant AppleLink: ogawa FAX:1/415/962-1969