========================================================================= Date: Thu, 1 Nov 90 04:41:17 LCL Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID ; THU, 1 NOV 90 05:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster I certainly feel too that whatever is deemed to be correct should be stated somewhere clearly. StvB ========================================================================= Date: Thu, 1 Nov 90 11:53:24 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: More about: change in DVI definition SB> That correction you sent out has no real implications SB> as far as FONTS are concerned, right?! The only change is that SB> now \specials CANNOT appear between pages anymore. TR> It would seem to me that the DVI file change is really nothing more TR> than a correction to the documentation. As far as I know, TeX never TR> wrote XXX commands before a PRE or between EOP and BOP. (If this had TR> been true, it would have given a better way of doing global specials: TR> output them at the end of the preamble just before the first BOP.) TR> TR> You are correct in assuming that the change does not affect fonts. DH> This is actually a reasonable approach; I presume that the change DH> was provoked by the question raised over the summer of what to do DH> with specials between pages when one was reordering pages. Since DH> no application currently available can produce specials in these DH> locations, the loss is negligible. My recommendation had always DH> been to ignore interpage specials anyway. SB> But then on the other hand: dvi files are NOT NECESSARILY SB> written by TeX. That's the reason I wanted the clarification. I noticed the DVI change when I collected *all* TeX file formats for barbara beeton [always lowercase...] It's the only change and I thought it should be updated in the DVI standard, too. What worries me in this context is that Don Knuth just changes file formats and introduces new file formats as he wants. You remember the ammendments 2 ff? It's about a change in the DVI format! What if this ammendment would have passed? What if we want to define that checksums of 0 shall be ignored? May we do this? Who is responsible for the whole stuff?! The DVI standards committee or Don Knuth? Will he accept changes from us? On another point: Tom Reid sent a mail that it is unclear where |xxx|-commands may appear. Please note the following excerpt from dvi.tex: DVI> If DVI> we ignore \id{nop} commands and \id{fnt\_def} commands (which are DVI> allowed between any two commands in the file), each \id{eop} command DVI> is immediately followed by a \id{bop} command, or by a \id{post} DVI> command; I think this makes it clear: |xxx|-commands may only appear within pages. Joachim ========================================================================= Date: Thu, 1 Nov 90 10:14:01 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: jsg@ARBORTEXT.COM Subject: specials between pages On rereading the DVItype manual it seems clear to me that specials are prohibited between pages of a dvi file. In the third paragraph of section 13, ``Device-independent file format'', it says: If we ignore nop commands and fnt_def commands (which are allowed between any two commands in the file), each eop command is immediately followed by a bop command, or by a post command;... ========================================================================= Date: Thu, 1 Nov 90 13:04:28 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: specials between pages In-Reply-To: Message of Thu, 1 Nov 90 10:14:01 EST from On Thu, 1 Nov 90 10:14:01 EST said: >On rereading the DVItype manual it seems clear to me that specials >are prohibited between pages of a dvi file. In the third paragraph >of section 13, ``Device-independent file format'', it says: > >If we ignore nop commands and fnt_def commands (which are allowed between >any two commands in the file), each eop command is immediately followed by >a bop command, or by a post command;... Thanks to John and Joachim for pointing this section out to me. It is now clear that XXX commands are not permitted between pages. I would favor adding a comment to the description of XXX or in a separate section on \special{}s indicating where the commands should be expected; especially since such a comment is present in the GF description. ---Tom Reid ========================================================================= Date: Fri, 2 Nov 90 08:53:10 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Short comment on call for quick \special{} standardization In-Reply-To: Don Hosek's message of Mon, 29 Oct 90 15:43:00 PST <9010300202.AA24246@june.cs.washington.edu> DH may have a good compromise there. Let us remember that the immediate inpetus for this discussion was a strongly worded plea for a single, simple graphics inclusion \special, and that this request was supported by the argument that such a \special would cover the needs of a vast majority of users. It should be possible to provide for this felt need without seriously compromising the search for the more complex syntax. 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, 2 Nov 90 11:03:57 LCL Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID ; THU, 1 NOV 90 14:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster Something like that should be part of the 'master DVI file description' in Volume B of Computers and Typesetting, right?! DVItype is in a sense a derived document, and therefore it can't be taken as the last work, can it?! Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Fri, 2 Nov 90 13:24:17 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: specials between pages Thomas J. Reid said: > I would favor > adding a comment to the description of XXX or in a separate section on > \special{}s indicating where the commands should be expected; especially > since such a comment is present in the GF description. Well, I want to repeat my first question: Are we able to add such a comment to the DVI definition? Who ``owns'' it? Are we really allowed to change it? From the comments of DEK about TeX and MF I think that *he* will not change it! (It's clear to me why DEK has not asked us about the DVI change -- it was a correction, not a change. But it would have been nice if he would have informed us, i.e., the comittee...) Joachim ========================================================================= Date: Fri, 2 Nov 90 14:11:45 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: More about: change in DVI definition (Joachim's message) In-Reply-To: XITIJSCH%DDATHD21.BITNET@UWAVM.U.WASHINGTON.EDU's message of Thu, 1 Nov 90 11:53:24 MEZ <9011011120.AA16181@june.cs.washington.edu> > What if we want to define that checksums of 0 shall be ignored? Has something changed? The last time I worked on a driver, which was indeed a long time ago, it was part of the specification that checksums of 0 in either the dvi file or the font/raster file should turn off checksum matching in the DVI interpreter. I can remember writing that little bit of code in explicitly. 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: Mon, 5 Nov 90 11:51: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: your mail Stephan v. Bechtolsheim said: > Something like that should be part of the 'master DVI file > description' in Volume B of Computers and Typesetting, right?! > DVItype is in a sense a derived document, and therefore it > can't be taken as the last work, can it?! Well, this section of DVItype is a copy of the starred section 31 of tex.web. Volume B (i.e., the printed version) is not updated, at least in the version distributed in Europe. Joachim ========================================================================= Date: Mon, 5 Nov 90 12:04:00 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: More about: change in DVI definition (Joachim's message) Pierre MacKay said: > > What if we want to define that checksums of 0 shall be ignored? > > > Has something changed? The last time I worked on a driver, > which was indeed a long time ago, it was part of the specification > that checksums of 0 in either the dvi file or the font/raster > file should turn off checksum matching in the DVI interpreter. > I can remember writing that little bit of code in explicitly. In the definition of PXL files (published in TUGboat long ago) such a statement appeared. But in no of the actual definitions, neither the TFM definition nor any of the font formats this is required. (Although DVItype implements this behaviour...) Shall we move the behaviour of DVItype into the standard? This should be an ammendment!! Joachim ========================================================================= Date: Mon, 5 Nov 90 11:51: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: your mail Stephan v. Bechtolsheim said: > Something like that should be part of the 'master DVI file > description' in Volume B of Computers and Typesetting, right?! > DVItype is in a sense a derived document, and therefore it > can't be taken as the last work, can it?! Well, this section of DVItype is a copy of the starred section 31 of tex.web. Volume B (i.e., the printed version) is not updated, at least in the version distributed in Europe. Joachim ========================================================================= Date: Mon, 5 Nov 90 12:04:00 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: More about: change in DVI definition (Joachim's message) Pierre MacKay said: > > What if we want to define that checksums of 0 shall be ignored? > > > Has something changed? The last time I worked on a driver, > which was indeed a long time ago, it was part of the specification > that checksums of 0 in either the dvi file or the font/raster > file should turn off checksum matching in the DVI interpreter. > I can remember writing that little bit of code in explicitly. In the definition of PXL files (published in TUGboat long ago) such a statement appeared. But in no of the actual definitions, neither the TFM definition nor any of the font formats this is required. (Although DVItype implements this behaviour...) Shall we move the behaviour of DVItype into the standard? This should be an ammendment!! Joachim ========================================================================= Date: Mon, 5 Nov 90 12:08:30 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: More about: change in DVI definition (Joachim's message) In-Reply-To: XITIJSCH%DDATHD21.BITNET@UWAVM.U.WASHINGTON.EDU's message of Mon, 5 Nov 90 12:04:00 MEZ <9011051112.AA24716@june.cs.washington.edu> The checksum behavior is also in the appendix to the dvistd, tfm.tex \item[{$\id{header}[0]$}] is a 32-bit check sum that \TeX\ will copy into the \str{DVI} output file whenever it uses the font. Later on when the \str{DVI} file is printed, possibly on another computer, the actual font that gets used is supposed to have a check sum that agrees with the one in the \str{TFM} file used by \TeX. In this way, users will be warned about potential incompatibilities. (However, if the check sum is zero in either the font file or the \str{TFM} file, no check is made.) The actual relation between this check sum and the rest of the \str{TFM} file is not important; the check sum is simply an identification number with the property that incompatible fonts almost always have distinct check sums. ========================================================================= Date: Mon, 5 Nov 90 21:52:31 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: zero checksums Pierre MacKay has pointed out that zero checksums are covered in the TFM definition. But I haven't found it neither in the GF nor in the PK definition so I think an ammendment with a clarification for these definitions is still needed. Joachim ========================================================================= Date: Mon, 5 Nov 90 14:48:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: TUG '91, driver standards Something of note to at least think about Date: Mon, 5 Nov 90 17:21 EDT From: John Lavagnino However, since September I've become the ``electronics editor'' of an edition of Thomas Middleton's works that the Oxford University Press is publishing. As you might imagine, this will use TeX and EDMAC for the printing. But using them directly didn't seem complicated enough, so instead our plan is to have the editors of individual works type them in using a simplified markup; we'll convert that here to SGML, and then convert that to TeX for the print edition. There's to be an electronic edition as well---or several, in whatever forms we think will be worthwhile; this is why we want to use SGML and the TEI guidelines for our principal electronic edition, and generate everything from that. A talk on all this may be of some interest for the meeting, but at the moment I don't really have much more than this to say about it and I don't know what will be most newsworthy about it all. March 15, 1991 is about when I plan to start really working a lot on it. I see that ``SGML and TeX and the publisher'' is one suggested topic, but in fact the publisher doesn't have a lot to do with this plan: we're going to be delivering camera-ready copy, and the use of SGML and TeX was our idea. In any case, I'll be thinking about this and may be able to come up with something by Dec 15; if you have any thoughts, let me know. I wanted also to bring up a question about DVI driver standards that has some connection with this edition. The electronic versions of this work will need to incorporate information about what the print version looks like, because nobody has thought of a way to handle references to such texts that's better than good old line numbers. But, of course, only TeX can tell us where the line breaks come out in prose. Rather than add this information back to the SGML version by hand, I intend to automate the procedure. But I think this will have to wind up using \special commands specific to this application, because the line numbers are hard to determine from a DVI file without other information---poetry, prose, and stage directions are all numbered in different ways, and are not necessarily easy for a program to distinguish. So \special commands to specify the line numbers are going to be needed. Obviously this is a specialized use that needn't be standardized. What could make things easier, though, is a standard mechanism for specifying comments or extended commands in DVI specials, so that a DVI file with all this extra junk in it could still be printed out. If this extra information looked like comments to other DVI processors, or like a standard sort of extension it knew it could skip (just as X- lines in Internet mail headers are just skipped), then life would be a bit easier; and it may be that other people will face problems similar to mine. John Lavagnino Department of English and American Literature Brandeis University Waltham, MA 02254 USA Internet: lav@binah.cc.brandeis.edu Bitnet: lav@brandeis ========================================================================= Date: Mon, 5 Nov 90 14:52:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: TUG '91, driver standards We haven't addressed the issue that you mentioned directly, but we certainly will be looking at a standard syntax for \special commands soon. (A lot of what soon means, unfortunately, is a bit too closely related to how my thesis goes, but...) A mechanism for specialized extensions like you proposed, however, should most likely be part of the basic syntax specification. -dh ========================================================================= Date: Fri, 9 Nov 90 11:03:56 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Gaulle Bernard Subject: Re: Short comment on call for quick \special{} standardization In-Reply-To: Message of Fri, 2 Nov 90 08:53:10 -0800 from I was very impressed by the letter of Theresea A. Ehling and Berthold K.P. Horn of MIT press and MIT artificial Int. Lab. in TeXhax V90#69 (sunday, November, 4) about \special standardization. Arguments are quite right. I think IT'S DANGEROUS FOR THE FUTURE OF TeX DRIVERS to remain the situation unchanged while many professionals, users, printers, publishers, etc. ask for a standardization of \special. So my feeling is that it's very important to DO SOMETHING NOW, may be a minimum standard as proposed by Pierre. I'd be pleased in the meantime that Nelson send us his proposal for his DVI3 drivers and that we look at it as a minimum requirement for the new versions of TeX drivers. I think that his drivers are extensively used around the world so they stand for a de-facto standard. To be acceptable I thing that Nelson's source code need to be released concurently in order that each developer can start from it. When we want we can do good things quickly, see the new character encoding scheme for example. This is my proposal who whants to second? Regards, Bernard GAULLE ========================================================================= Date: Fri, 9 Nov 90 13:03:55 +0100 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jan Michael Rynning Subject: Re: Short comment on call for quick \special{} standardization In-Reply-To: Your message of Fri, 9 Nov 90 11:03:56 EDT I second Bernard Gaulle's proposal to standardize \special as quickly as possible. If we can agree on using Nelson Beebe's grammar, what remains is to define a list of tags and permitted values. For the future, we'll need a registry for \special tags and keywords. Here are some of Nelson's tags and keywords: Tag Value include file name language one of these keywords: postscript, dvixxx, ... ... PSfig has a nice user interface, similar to the grammar Nelson proposed for \special, but the \special commands produced by the PSfig macros are horrible. It souldn't be too hard to rewrite the PSfig macros and make them produce \special's which comply with Nelson's grammar. Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288 ========================================================================= Date: Fri, 9 Nov 90 12:53:13 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Adrian F Clark Subject: Re: Short comment on call for quick \special{} standardization In-Reply-To: Gaulle Bernard's message of Fri, 9 Nov 90 11:03:56 EDT <3888.9011091213@ese.essex.ac.uk> > This is my proposal who whants to second? > Regards, > Bernard GAULLE Me. Adrian F. Clark JANET: alien@uk.ac.essex INTERNET: alien%uk.ac.essex@nsfnet-relay.ac.uk FAX: (+44) 206-872900 BITNET: alien%uk.ac.essex@ac.uk PHONE: (+44) 206-872432 (direct) Dept ESE, University of Essex, Wivenhoe Park, Colchester, Essex, C04 3SQ, UK. ========================================================================= Date: Mon, 12 Nov 90 11:22:05 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Short comment on call for quick \special{} standardization Gaulle Bernard said: > I think that his drivers are extensively used > around the world so they stand for a de-facto standard. In what version? A lot of people I know of use *very* old versions, and are quite satisfied (even if characters are shaking because of an error in the placement algorithm -- I know this error, we had done the same in our driver family...) > To be acceptable > I thing that Nelson's source code need to be released concurently in order > that each developer can start from it. Please note: not every driver is written in C, if it is written in C it perhaps uses complete other conventions, and not everybody uses Nelson's drivers! So this is not a `starting point' but an `example of how it *may* be done.' > When we want we can do good things quickly, see the new character encoding > scheme for example. Well, that's really a nice example (I was in this committee). We have now a coding scheme for text fonts where all math chars were thrown of. Anybody out there with a proposal for math fonts? Has anybody thought about writing a new plain.tex (which may not be called Plain anymore!), a new lfonts.tex. What about math families, bold gammas, etc.? Implementing all the stuff the users are accompanied to! The existing proposal is an advantage, but not a success -- we are stuck in the middle. > This is my proposal who whants to second? My critical comments shall not express that I'm against a standardization of tags and keywords now. They just shall warn that it is not that easy as it sounds in the first moment. There is a great danger in doing a little bit and then stopping. A lot of people complaining about the DVI standard being slow. Well, that's partly because the voting members don't work as they should. Ammendments are out for too long and no votes are coming in. Robert McGaffey (the first head of the committee!!) and Ralph Youngen have never voted at all. Ammendment 8 was out for more than 4 weeks, no comments on ammendment 09--12 till now. No comments on important proposals which seems to be work and not fun (like John's proposal on how to incorporate a trip test into commercial drivers). Where are the *concepts* of the verification (trip test) the draft talks about? Not to talk about a realization! So I fear of a *slow* process in the future -- like in the past! Joachim ========================================================================= Date: Mon, 12 Nov 90 19:25:53 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Joachim Schrod's comments on the standardization process In-Reply-To: Message of Mon, 12 Nov 90 11:22:05 MEZ from Joachim Schrod sums up my feelings quite accurately! His comments on the 256 character fonts stresses some important points which we need to consider when designing specials: That is, we need to do more than just standardize the syntax and specific keywords: we need to consider (although not necessarily define syntax for) how the TeX user would make use of the features. We should also come up with a general philosophy over the level of functions which should be implemented in specials. Further, we need to allow a syntax which allows DVI drivers to experiment with new specials in a way which will not interfere with standard ones as well as to coordinate, in some manner, development of specials. However, one point which Joachim omitted from his comments on the new character encoding scheme is, assuming that all of his other points are met, how will the new method be phased in and the old one phased out? It may very well be the case with the new character encoding scheme that it can be implemented in a "transparent" way; I don't think that this will be possible with specials. John Gourlay pointed out some time ago that he can not ignore his existing customer base and abandon existing specials. This is a very important point. Joachim's comments point out the necessity to do more than just adopt a standard for a small aspect of something. I feel that before we begin to design a syntax, we need to examine and agree upon how specials are used---not what they are used for, but "who" uses them. Who or what generates the specials serves to determine the syntax, the degree of error recovery and level of diagnostics which the driver should provide, and, most importantly, the level of capability must be supported by a given special. To try to talk about a syntax for specials without having a common philosophy on them would be futile. Once we develop a general approach and design a basic syntax, I think that we should allow individuals or groups of people to experiment with specific capabilities. We, or some committee within TUG, should then coordinate assimilating these into a standard and make them available to driver authors. This process is somewhat like the process by which the TCP/IP and associated protocols have been (and are still being) developed. TUG should promote experts in specific areas to experiment with various specials to find out what works and what doesn't before trying to set features into a standard. ---Tom Reid ========================================================================= Date: Tue, 13 Nov 90 17:08:42 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Gaulle Bernard Subject: re:Joachim's comment Joachim said: > a lot of people ... use *very* old versions, (of Nelson's Drivers) > and are quite satisfied Yes. So they don't need a new standard since they are satisfied. > Not every driver is written in C Yes. It's an example of how it may be done. >a proposal for math fonts? this is not the main goal of this list. > about a new plain.tex .... same comment and yes, people think about that. > it is not that easy as it sounds Right, but if we allways say that it's too difficult for us we never work on it. My proposal has the advantage to simplify the processus and to find rapidely a consensus, may be, on Nelson's scheme. > voting members don't work as they should. > Amendments are out for too long ... > no comments on amendment 09--12 till now Sorry, but this committee is under the management of Don Hosek. And I didn't hear that he asked we vote on these amendments. When he come back and he asks for I'll vote promptly. 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 strongly reject pessimism. For TeX users, Bernard GAULLE ========================================================================= Date: Tue, 13 Nov 90 17:43:46 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: A proposal for a TeX \special... Instead of reading a great pile of TUG board mail, I worked hard this weekend and completed a proposal for the handling of TeX \special and paper specifications. This is in a form intended for TUGboat publication, and expands upon the material I've previously posted to this list. The complete set of files needed to print this document is about 80KB; I would like to post it to this list as a UNIX shar bundle (unpacking on other systems is not difficult). However, there is the encoding problem. Can those of you who cannot get printable ASCII through successfully use FTP to retrieve the files? The tuglib server will soon have an encoding scheme that solves this problem; I finally got mail back today from Niel Kempson on the work they've been doing merging their vvencode work with my xxencode. In the meantime, however, uuencode doesn't survive some Bitnet and Janet gateways. ======================================================================== 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@science.utah.edu ======================================================================== ========================================================================= Date: Tue, 13 Nov 90 17:08: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 0.04a I've just finished incorporating the assorted typo corrections &c. into the 0.04 version of the standard. A list of differences concludes this message; those who would rather just get the updated file can either FTP it from ymir.claremont.edu : [anonymous.tex.dvi-standard]level0-draft.tex or receive it from mailserv@ymir.claremont.edu by sending the command: send [tex.dvi-standard]level0-draft.tex (incidentally, I'd be curious to hear from a Janet person whether our mailer is in fact bypassing the nasty gateways successfully). ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 5 \date{Version 0.04a\\Last revised 13~November~1990 6 ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 5 \date{Version 0.04\\Last revised 6~October~1990} 6 ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 24 \vskip1pt 25 \leavevmode{\setbox0=\lastbox}\small 26 {\bf Explanation:}}{\par} 27 \fi ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 24 \leavevmode{\setbox0=\lastbox}\small 25 {\bf Explication:}}{\par} 26 \fi ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 36 \def\abs{\mathop{\rm abs}} 37 \def\round{\mathop{\rm round}} 38 ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 35 \def\abs{\hbox{abs}} 36 ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 48 ensure that their programs meet the standards developed here. The 49 specifications here should be considered a minimum requirement; ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 46 insure that their programs meet the standards developed here. The 47 specifications here should be considered a minimum requirement; ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 93 characters; a full page bitmap is also not possible with this 94 configuration. ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 91 characters, a full page bitmap is also not possible with this 92 configuration. ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 125 not subject to the exception for device limitations 126 of Section~\ref{escape-clause}. 127 \end{explicate} ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 123 not subject to the exception of Section~\ref{escape-clause}. 124 \end{explicate} ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 176 the location given by rounding the current \DVI\ coordinates as 177 indicated in Section~\ref{rounding-algorithim}. The height and ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 173 the location given by rounding the current \DVI\ co\"ordinates as 174 indicated in Section~\ref{rounding-algorithim}. The height and ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 219 processors ({\em e.g.,\/} screen previewers), 220 this specification refers to a virtual page and not 221 the physical output. 222 \end{explicate} ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 216 processors, this specification 217 \end{explicate} ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 243 For a horizontal movement of $x$ \DVI\ units from any other command, 244 ${\it hh}$ will be set to ${\it hh}+\round(x)$ if 245 $x < {\it word\_space}$ for a horizontal movement to the right or if 246 $x > -{\it back\_space}$ for a horizontal movement to the left. 247 If the movement is greater than the specified amounts, ${\it hh}$ 248 should be set to $\round(h+x)$ 249 {\it 250 word\_space\/} is defined as $\it space - space\_shrink$, and {\it 251 back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt ****** File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;1 238 For a horizontal movement from any other command, ${\it hh}$ 239 should be set to be ${\it hh}+{\it round}(x)$ if 240 $x < {\it word\_space}$ for a horizontal movement to the right or if 241 $x > -{\it back\_space}$ for a horizontal movement to the left. {\it 242 word\_space\/} is defined as $\it space - space_shrink$, and {\it 243 back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt ************ ************ File TEX_ROOT:[DVI-STANDARD]LEVEL0-DRAFT.TEX;2 260 For a vertical movement of $y$ \DVI\ units, 261 ${\it vv}$ is set similarly except that 262 $\it vv$ is set to ${\it vv}+\round(y)$ if $-0.8{\it 263 quad} Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: DVI standard 0.04a For the European folks: The new draft standard will be available from listserv@dhdurz1.bitnet. Send a mail with the line get dvistd0 tex driver to the Listserver. But wait a few days: Don sent me the draft but it was damaged on the way. I have ordered a new one from ymir and will install it when it arrives. If you order an index of the driver filelist, i.e., send a mail with the line index driver to the Listserver, you may check the date if I have installed it already. Joachim ========================================================================= Date: Wed, 14 Nov 90 18:49:21 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: draft 0.04a There are still errors in the draft sent out by Don. Some of mine ammendments have got obsolete, a seperate mail on this topic will be sent. Below is the diff which is still needed for the standard. Please note that the draft was even not TeXable. Therefore I will *not* place the draft 0.04a on the Bitnet listserver before I did not receive an answer from Don Hosek concerning the state of my changes given below. Changes: 1. forgotten '}' 2. if \round is defined it should be used, too. 3. $hh$ is still h times h, and not the variable hh! 4. the term x-escapement is still defined nowhere, it must read `horizontal escapement.' 5. the sentence in lines 247--249 is unnecessary as this is explained at the end of this paragraph. 6. Line 278 with `inches' must be discarded. context diff: *************** *** 2,8 **** \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04a\\Last revised 13~November~1990 \font\tensl=cmsl10 --- 2,8 ---- \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04a\\Last revised 13~November~1990} \font\tensl=cmsl10 *************** *** 230,252 **** $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ! ${\it hh}={\it round}(h)$ or ${\it vv}={\it ! round}(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using pure \DVI\ units. If the change in position is due to a {\it ! set\_char} command, the driver should add the x-escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the ! new value for $hh$. For a horizontal movement of $x$ \DVI\ units from any other command, ${\it hh}$ will be set to ${\it hh}+\round(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if ! $x > -{\it back\_space}$ for a horizontal movement to the left. ! If the movement is greater than the specified amounts, ${\it hh}$ ! should be set to $\round(h+x)$ ! {\it word\_space\/} is defined as $\it space - space\_shrink$, and {\it back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design --- 230,248 ---- $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ! ${\it hh}=\round(h)$ or ${\it vv}=\round(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using pure \DVI\ units. If the change in position is due to a {\it ! set\_char} command, the driver should add the horizontal escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the ! new value for $\it hh$. For a horizontal movement of $x$ \DVI\ units from any other command, ${\it hh}$ will be set to ${\it hh}+\round(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if ! $x > -{\it back\_space}$ for a horizontal movement to the left. {\it word\_space\/} is defined as $\it space - space\_shrink$, and {\it back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design *************** *** 254,260 **** magnifications have been applied) may be used for a {\it quad}, and {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be ${\it round}(h+x)$. In this way, rounding errors are absorbed by interword spaces. For a vertical movement of $y$ \DVI\ units, --- 250,256 ---- magnifications have been applied) may be used for a {\it quad}, and {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be $\round(h+x)$. In this way, rounding errors are absorbed by interword spaces. For a vertical movement of $y$ \DVI\ units, *************** *** 267,281 **** After any horizontal movement, a final check is made as to whether $\abs(Kh-{\it hh})>{\it max\_drift}$. If it is, then $\it ! max\_drift$ is added or subtracted to $hh$ to bring it closer to $Kh$. A similar check is made with $\it vv$ and $v$. $\it ! max\_drift$ should be set to~$2$ for output devices with device ! units smaller than or equal to 0.005\in\ (0.127\mm), $1$~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! $0$~for output devices with device units greater than 0.01\in\ (0.254\mm). - inches. \end{standard} \subsubsection{Range of movement} --- 263,276 ---- After any horizontal movement, a final check is made as to whether $\abs(Kh-{\it hh})>{\it max\_drift}$. If it is, then $\it ! max\_drift$ is added or subtracted to $\it hh$ to bring it closer to $Kh$. A similar check is made with $\it vv$ and $v$. $\it ! max\_drift$ should be set to~2 for output devices with device ! units smaller than or equal to 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! 0~for output devices with device units greater than 0.01\in\ (0.254\mm). \end{standard} \subsubsection{Range of movement} *************** *** 425,431 **** \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 locate size information for the font in question, then the processor may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands --- 420,427 ---- \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 locate size information for the font in question, then the processor may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands --- end of mail ========================================================================= Date: Wed, 14 Nov 90 19:34:07 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: ammendments 09--12 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. Ammendment 10 (definition of round() in section 2.6.2) is to be renumbered as ammendment 09. There was an error, I send it therefore again as separate mail. Ammendment 11 (change of max_drift correction) is to be renumbered as ammendment 10. There was no error, therefore I do not send it out again. Joachim ========================================================================= Date: Wed, 14 Nov 90 19:35:36 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Ammendment 09 (new one) Ammendment: definition of round() in section 2.6.2 Ammendment number: 09 Submitted by: Joachim Schrod Date: 14 Nov 90 Reason for change: This ammendment changes the name of the function round() in Section 2.6.2 to pixel_round() and defines pixel_round(). Please note that the change of the name was done in the macro \round. The ammendment is given as a context diff, assuming draft 0.04a at it's base. This new ammendment results in the draft 0.04b. *** dvistd4a.tex Wed Nov 14 18:38:08 1990 --- dvistd4b.tex Wed Nov 14 19:05:08 1990 *************** *** 34,40 **** \def\in{\,in} \def\PK{{\tt PK}} \def\abs{\mathop{\rm abs}} ! \def\round{\mathop{\rm round}} \begin{document} \maketitle --- 34,41 ---- \def\in{\,in} \def\PK{{\tt PK}} \def\abs{\mathop{\rm abs}} ! \def\round{\mathop{\rm pixel\_round}} ! \def\sign{\mathop{\rm sign}} \begin{document} \maketitle *************** *** 230,236 **** $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ! ${\it hh}=\round(h)$ or ${\it vv}=\round(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using --- 231,239 ---- $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ! ${\it hh}=\round(h)$ or ${\it vv}=\round(v)$ where $\round(n)$ is ! defined as $\sign(Kn) \cdot \lfloor \abs(Kn) + 0.5 \rfloor$ with ! $\sign(i)$ resulting in~$-1$ if~$i<0$ and in~$1$ otherwise. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using --- end of ammendment ========================================================================= Date: Wed, 14 Nov 90 19:34:07 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: ammendments 09--12 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. Ammendment 10 (definition of round() in section 2.6.2) is to be renumbered as ammendment 09. There was an error, I send it therefore again as separate mail. Ammendment 11 (change of max_drift correction) is to be renumbered as ammendment 10. There was no error, therefore I do not send it out again. Joachim ========================================================================= Date: Wed, 14 Nov 90 15:24:21 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: A proposal for a TeX \special... In-Reply-To: "Nelson H.F. Beebe"'s message of Tue, 13 Nov 90 17:43:46 GMT <9011140055.AA19330@june.cs.washington.edu> Ready to FTP. But we need the file name and location. ========================================================================= Date: Thu, 15 Nov 90 11:58:20 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Gaulle Bernard Subject: Re: A proposal for a TeX \special... In-Reply-To: Message of Tue, 13 Nov 90 17:43:46 GMT from About sending Nelson's 80K proposal: SHAR is often ok for me and i can also get it via FTP. Out of my office yesterday 60 messages came in my mailbox BUT were unfortunatel y lost during a curious session of MAIL under my VM/CMS... Bernard GAULLE ========================================================================= Date: Thu, 15 Nov 90 14:00:18 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: CA_ROWLEY%vax.acs.open.ac.uk@RELAY.CS.NET Subject: RE: DVI standard 0.04a It is getting to the following uncorrupted: To: Adrian Clark , Chris Rowley > > (incidentally, I'd be curious to hear from a Janet person whether our mailer is > in > fact bypassing the nasty gateways successfully). here is a test to see if it is also OK from JANET via this route. ***************************************************************************** Character reference: Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ Lower case letters: abcdefghijklmnopqrstuvwxyz Digits: 0123456789 Query, exclamation, comma, colon, semi-colon, period: ? ! , : ; . Square brackets, curly braces: [] {} Angle brackets, round parentheses: <> () Backslash, slash, vertical: \ / | Hyphen, underscore, equals, plus: - _ = + Quotes---right, left, double: ' ` " Tilde, at-sign, dollar, percent: ~ @ $ % Hat(up-arrow), ampersand(and), asterisk(star): ^ & * Hash(sharp, number, pounds!!!): # Finis ****************************************************************************** ========================================================================= ========================================================================= Date: Mon, 26 Nov 90 09:50:14 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: Resent-From: "Thomas J. Reid" Comments: Originally-From: "Thomas J. Reid" From: "Thomas J. Reid" Subject: Re: Tom Rokicki's suggestion about rule thicknesses In-Reply-To: Message of Wed, 31 Oct 90 15:24:31 -0800 from Note from DRIV-L list co-owner: The LISTSERV disk used to keep DRIV-L logs filled up last Wednesday and caused the list to be held. LISTSERV indicated that the sending of my posting (the note which follows) was being postponed. The problem has since been fixed but my note does not show up in the log. (The last note in the log is one from Chris Rowley sent on Thu 15 Nov 90.) Therefore, I am reposting this note. Apologies to anyone who may receive it twice. ---Tom Reid ----------------------------Original message---------------------------- Since nobody else has replied to Tom Rokicki's detailed note about computing rule lengths/thicknesses in a different way to reduce alignment problems, I thought that I would test his proposal and report on it. Making the corners of boxes line up has long been an issue with me, so I was glad to see Tom's proposal. The approach which I have taken has been to treat the problem as an "application level" issue and make adjustments in how the rules are done (details later in this note). Thus, my approach requires that changes be made to the TeX code creating boxes, but always results in proper alignment. Rokicki's approach, however, does not require changes (or involves simpler changes), but does not ensure correct alignment. Fortunately, neither approach precludes the other; so both can be used. In implementing Rokicki's approach, I did not run across any surprises; the results I got were consistent with his analysis. One point to note when implementing this is that horizontal and vertical are not symetric: widths over 10 pixels, the width is computed by rounding h and h+width to pixels then subtracting while the height over 10 is computed by rounding v and v-height (not v+height) to pixels and taking the difference. (I failed to note this at first and the results were worse than just using the plain "DVItype" method.) My approach is to accept that rounding problems such as Rokicki describes can and do occur and control it by minimizing the number of h and v positions that are used. This is best shown pictorially. First, four rules are drawn to make the box: (In my drawing, each rule is shown as four horizontal or vertical lines. The pluses show where two rules overlap.) -------------------------------------------- -------------------------------------------- ++++--------------------------------------++|| v2. ++++--------------------------------------++|| |||| |||| |||| |||| |||| |||| |||| |||| ++++--------------------------------------++|| ++++--------------------------------------++|| ++++--------------------------------------++|| v1. ++++--------------------------------------++|| . . h1 h2 There are several points to note: o There are only two distinct h and two distinct v values for the lower-left corners of the rules. (BTW: My method assumes that the guidelines we have in place in the DVI standard are followed.) o The rules extend halfway into the rules perpendicular to them on the top and right. This serves to (1) prevent overshoot if roundoff makes the rule too long (as per Rokicki's analysis), and (2) prevents shortfall if roundoff makes the rule shorter. o There is a defect in the upper-right corner of the box. The use of only two h and v values as well as consistent rule thicknesses (height+depth or width as appropriate) ensures that the other corners line up correctly. The only problem is to fill in the upper-right corner. This is easily done adding a fifth rule with a lower left at (h2, v2) and a height and width equal to the rule thickness. As long as one does this in a manner to avoid any roundoff errors in TeX's arithmetic with dimensions, the box corners will all line up. In actual implementation, it may not be convenient to compute the proper lower-left positions and correct rule lengths. A technique which I have used successfully is to make the box with six rules each of which is centered on the desired corners of the box. In TeX terms, this is: \newdimen\X \X=... % the left edge of the box \newdimen\Y \Y=... % the bottom edge of the box \newdimen\H \H=... % the height of the box \newdimen\W \W=... % the width of the box \newdimen\R \R=... % the thickness of the rules making up the box \newdimen\RH \RH=0.5\R % avoid problems with \R values of an \newdimen\RR \RR=2\RH % odd number of scaled points \def\P#1, #2, #3{\rlap{\kern#1 \raise#2 \hbox{#3}}} \hbox to ... {\P \X, \Y, {\hbox to 0pt{% \P 0pt, 0pt, {\vrule height \RH depth \RH width \W}% \P 0pt, \H, {\vrule height \RH depth \RH width \W}% \P 0pt, 0pt, {\kern-\RH \vrule height \H depth \RH width \RR}% \P \W, 0pt, {\kern-\RH \vrule height \H depth \RH width \RR}% \P 0pt, \H, {\kern-\RH \vrule height \RH depth \RH width \RR}% \P \W, \H, {\kern-\RH \vrule height \RH depth \RH width \RR}% \hss}\hss} Advantages/disadvantages: Tom Rokicki's method has the advantage of being much easier on the TeX user than does my method but it is not always successful. The proba- bility of success can be controlled by having the user set a resolution- dependent parameter. Conversely, mine is harder, but is guaranteed. For someone developing a macro package, it would be better to spend the effort to use my method. Tom Rokicki's method has its greatest advantage in improving the rules without the TeX user making any changes at all. Thus, let's see how it performs for the most typical cases. The assumptions for "typical" are: o No rule thickness is given; TeX defaults to 0.4pt. For the following resolutions, the pixel widths of the rules are: o 240 dpi: 1.3284 pixels o 300 dpi: 1.6604 pixels o 400 dpi: 2.2139 pixels As Tom indicates, the probability of misalignment will be *less* as the fractional part of the width in pixels approaches (but does not exceed) 1. None of these resolutions gives widths with fractional values very close to 1, although 300, the most predominant resolution right now, comes the closest. The approach does give an improvement. How does this all fit into the DVI Driver Standard? Tom Rokicki's approach deals with matters internal to DVI drivers and could clearly be adopted into the standard. My method, however, does not; it concerns how to use the next level up to avoid rounding problems. Unfortunately, this does not have a place in the present standard. I would hesitate to include Rokicki's approach without addressing mine in some way because it can give the false impression that the problem has been studied and resolved. I do like the approach and plan to keep it in my driver (unless the standard specifically requires the current "DVItype" method). Further comments? ---Tom Reid ========================================================================= Date: Mon, 26 Nov 90 10:11:05 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: What's the rule on rule drift Another issue which occurred to me when I was testing Tom Rokicki's approach to rule thicknesses is: "Should rules participate in the 'max drift' algorithm?" That is: "Should rules be allowed to drift like words?" In DVI driver implementation terms, this question becomes: "Should the lower left of rules be set to (hh, vv) or to (pixel_round(h), pixel_round(v))?" Drifting rules clearly represent a problem for aligning box corners; but if a word is underlined, the underline should drift with the word. Vertical drift is also desired for rules within equations as is hori- zontal drift for overbars in radicals and such. I have not done a detailed enough study of how TeX constructs DVI files for doing math or all of the circumstances surrounding drawing boxes. In many cases, the horizontal or vertical motion will be enough to force hh and vv to be recomputed from h and v (ie, no drift). However, I am not convinced that this will be true in all cases when it should be true, and not when rules should be allowed to drift. Further, there is the problem that drift limits are defined in terms of font metrics. DVI opcodes, of course, don't use fonts to draw rules. A set_rule or put_rule may appear on a page before any fonts are defined, so one cannot just use the limits of the "current font." More comments? ---Tom Reid ========================================================================= Date: Mon, 26 Nov 90 20:37:27 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: A proposal for a DVI "trip test suite" In-Reply-To: Message of Mon, 12 Nov 90 11:22:05 MEZ from In his note of 12 Nov 90, Joachim Schord points to the lack of response to defining a driver "trip test" and indicates that it is because this is work and not fun. To a large degree, he is correct. However, perhaps another reason is that the problem of a "trip test" is too vague and there have been few attempts to define the problem. The following is my attempt to define the requirements for a DVI driver test suite. (I say "suite" because I don't think that a single file can test all of the things we ought to test.) Questions to be resolved: 1) What is to be tested by this test suite? 2) How are the tests to be done? 3) How and in what form will the test suite be disseminated? 4) Who will run a driver through the test suite? 5) How are results of the test suite to be documented? Questions 3 through 5 are the easiest to answer. My answers to them are: 3) A series of source files (TeX, MF, etc.) as well as existing binary files (DVI, GF, PK, etc.) will be placed on various archives and advertised in our standards document. 4) The author of a driver would be expected to run the test suite. Users of the driver should also have the ability to retrieve and run the test suite --- perhaps not all of it, but at least some of it (see response to next question). 5) The author should document the level to which the driver passed. This "level" refers to the discussions that we had on the number of characters and rules per page and the size of the characters which the driver/device could handle. My thoughts are that the test suite should include TeX and MF input files which contain multiple pages with increasing numbers of characters/rules and differing character sizes. The driver author could then report something like: "The Model 123 printer with options A, B, and C can handle all but page x of the test suite." If the set of pages in the test suite are documented somewhere (such as printed in TUGboat), users could look at the pages and get a much better idea on page complexity than just seeing a count of the number of characters/rules. Of course, it would be too much of a burden on driver authors to expect them to test all printer models with all options. Therefore, this part of the test suite must be made available to users of the driver (perhaps we should recommend/require that this part be included in the driver distribution file). This would allow users to test the driver on the model which they have. For questions 1 and 2, a series of points need to be identified. Some possible ones are: o Resilience of a driver to mal-formed DVI files. While the present Level 0 seems to assume properly-formed files, it would make sense for drivers to do some sanity checking of the file. According to our present standard, a driver is required to handle 100 PUSHes before getting a POP. The standard does not say what a driver should if it gets 101 PUSHes; the driver seems to be free to write over whatever happens to follow (or precede) the stack in memory and subsequently bomb out. Level 0 should have some statement (such as Guntermann and Schrod put in their article on high- quality output drivers) concerning this type of behaviour. For Level 0, I think that it would be acceptable for a driver which detects a mal-formed DVI file to simply report it and terminate processing with instructions to run DVItype to find out what is wrong with the file. Higher levels of the standard can specify more graceful recovery actions. At level 0, we should not expect that many tests be done. For example, it should not be required that the driver ensure that all FNT_DEFs occur in pairs (once in the postamble and once in the body) and that they reference the same font at the same size. However, the driver should ensure that any font called by a FNT_NUM0--FNT_NUM63 or FNT1, FNT2, FNT3, or FNT4 has been defined. The general rule is that the driver should check for anything that may otherwise cause it to bomb out. Some things to test for are: -- Existence of a PRE and DVI format identifier at the start of a file. (This is to ensure that the file passed to the driver is in fact a DVI file or that there was no obvious problem in transmitting the file, such as an ASCII-to-EBCDIC translation on it.) -- Checking for defined fonts and fonts within the range specified by the standard. -- Checking for character codes within the range specified by the standard. -- Checking that the character is defined in the given font (if this would cause a problem otherwise). -- Recognizing invalid opcode bytes in the DVI file or illegal codes in the postamble. -- Too many PUSHes or more POPs then level currently stacked. (Ie, check for stack overflow and underflow.) -- More? How should these things be tested? Normally, TeX does not create such invalid DVI files. Some time ago, I posted a DVIasm program which I used to build illegal DVI files. We could use that to build the test DVI files, then distribute all of: (1) the source to DVIasm; (2) the DVIasm inputs used to build the DVI files; and (3) the DVI files. This would allow people on systems for which DVIasm has not been ported to get the already built DVI files and test with them. o Compliance of the driver to the limits of the standard. As I stated earlier, this could be done with TeX and MF files giving numerous pages and characters of an increasing complexity. We should probably have some pages which test the absolute limits along with a set of pages of "typical" text which serve to give the users an idea of the page complexity which will print. For the present, the "typical" text should exist in more than one language since separate printer codes may be required to make accented letters and will reduce the limit of letters per page. (Once true 256-character fonts are in widespread use, this multi- language requirement can be dropped.) Back when we were discussing limits of characters and rules per page, a recent graduate of TAMU, Mark Motl, sent me a TeX file which would print fine on one device, but would not print one certain page with my driver. A table he had on that page looked straightforward, but on closer inspection, I found that it was made up of some 1400 rules and 1200 characters. I have since received Dr. Motl's permission to include the file as a test file in our DVI test suite (although we may want to reduce the number of rules to around 1000). o Test compliance of driver w.r.t. character drift. John Gourlay has already pointed out a problem with checking compliance for object-code only drivers. Joachim Schrod suggested to me having drivers output a stream of messages giving each character together with its font number and position (position being the hh and vv coordinates) in response to some execution option or perhaps a debug mode of the driver. This output would then be compared with output from some DVItype-like processor. The precise format for this output would have to be given, but this should not be a big issue. (If a driver author can follow the "max drift" algorithm, then he or she should not have any problems following a format description.) Should the end-user be able to run this test? Or should it simply be up to the driver author? My feeling is that we could trust the author to test the algorithm. If a driver author wishes to include the code in a production driver, this will be fine as well. o A driver should be able to work with scaling factors in the DVI preamble/postamble other than that which TeX uses. That is, the driver should not assume that DVI units are in scaled points. To test this, we could either include a DVI file produced by a DVI file generator which assumes different units, or we could create the DVI file using DVIasm. o More things to test? Suggestions anyone? ---Tom Reid ========================================================================= Date: Tue, 27 Nov 90 16:46:20 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: DVI driver test suite Thanks for your excellent posting, Tom (Reid), on requirements for a DVI driver test suite. I quite agree that a suite, not a single test file, is needed. A suite can cover more ground, and importantly, is EXTENSIBLE. It therefore ought to be given a revision number and date so that it can be updated as needed. dviasm will be essential for constructing devious, or unusual, or invalid, DVI files for testing purposes. We do need to test drivers with DVI files that may not have come from TeX, since we know that such programs exist already. ======================================================================== 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@science.utah.edu ======================================================================== ========================================================================= Date: Wed, 28 Nov 90 14:40:33 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Gaulle Bernard Subject: Re: A proposal for a TeX \special... In-Reply-To: Message of Tue, 13 Nov 90 17:43:46 GMT from Nelson, Is it possible to read your 80K shar file about \special? Thanks, Bernard GAULLE PS: I've also few other important things to tell you if it is possible to have a little discussion over the net. ========================================================================= Date: Wed, 28 Nov 90 22:06:15 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: DVI driver test suite In-Reply-To: Message of Tue, 27 Nov 90 16:46:20 GMT from Based on the practice of "he or she who suggests, volunteers," I have begun a collection of files for this test suite. I will organize the files and make them available for anonymous FTP. I am also considering making them available through LISTSERV. (Joachim: If I do this, could you keep a duplicate copy on the Heidelburg server for the benefit of within EARN?) As we approve new major releases of the test suite, the files should be moved to the "official" TeX servers. Nelson Beebe writes: >... >A suite can cover more ground, and importantly, is EXTENSIBLE. >It therefore ought to be given a revision number and date so >that it can be updated as needed. These are both good points. The dvi-test/README file which I keep will have a version number and date as well as a listing and brief description of each of the individual test files. >dviasm will be essential for constructing devious, or unusual, >or invalid, DVI files for testing purposes. We do need to test >drivers with DVI files that may not have come from TeX, since we >know that such programs exist already. Yes, we should include DVI files created by non-TeX DVI generators. I do not have access to any at this time, so I will need a co-volunteer to generate some and send them to me. The work that I've done thusfar is to write a "first round" summary of the test suite and to write and test the first two files listed in the summary. Before I spend more time writing other files in the suite, I would like some feedback on a number of things: o Whether or not specific tests should actually be included. The current tests in the DVI validity section serve two functions: -- Guard against common errors which can happen such as users trying to run the driver on a .tex file and DVI files that get corrupted when transmitted between systems; and -- Do sanity checks on DVI files which pass the first set of test. The first set definitely needs to be included; I have mixed feelings on the second set. The second set basically checks to see if the DVI generator has done its job correctly. While it is a good practice for programs to check all of their input, the number of possible wrong ways to construct a DVI file is *quite* large. Most tests will result in the driver quitting, so you only get one bad construct per test resulting in lots of little .dviasm files. o I have included a copy of one of the tests at the end of this note. I would like any comments on it that anyone might have. I do not intend to post all tests to the list; only the summary may get posted from time-to-time. Anyone else wanting the tests will be able to get them from a server. o Structure of the test suite: What other categories should be included and what tests should be added to existing and new categories? o Finally, Help!: Like everyone else on the list, I do not have an abundance of spare time to devote to this task. I can make all of the .dviasm files and perhaps some of the .tex ones. I ask for volunteers for other .tex files as well as the .mf one(s) (I know very little METAFONT.) Also, anyone with non-TeX DVI generators will need to send me a DVI file or a copy of the program as well as some input for it. The rest of this note contains a copy of my current README file and the preamble/bad-id.da file. (I have changed the filetype ".dviasm" to ".da" to reduce the length of the file names. Fourteen characters is UNIX Sys V's limit.) ---Tom Reid ------------------------------start of README--------------------------- This is the TUG DVI Driver Test Suite Version 0.0 as of 28 Nov 90. The files in this collection comprise the TUG DVI Driver Standards Committee's DVI Driver Test Suite. The function of this suite of files is to test various features of DVI drivers and their compliance with the TUG DVI Driver Standards. The tests are divided into the following categories: > directory-name/ -- file-name level description o Validity testing for DVI file structure: > preamble/ Preamble tests -- no-PRE.da 0 Missing PRE at start of file -- bad-id.da 0+ Invalid DVI format code > postamble/ Postamble tests -- no-dfsig.da 0 Invalid "signature" at end of DVI -- bad-id.da 0 Invalid DVI format code -- no-POSTPOST.da 0 No POST_POST at end of file -- bad-qptr.da 0 Invalid back pointer in POST_POST -- no-POST.da 0 POST_POST ptr does not point to POST -- bad-pptr.da >0 Invalid back pointer in POST -- incon-scale.da >0 Different scales in PRE and POST -- bad-op.da 0 Invalid opcode -- body-op.da 0 Body DVI code found in postamble > body/ DVI body tests -- all-ops.da 0 Tests all valid DVI opcodes -- bad-op.da 0 Invalid opcode -- bad-FNT.da 0 Reference to undefined font -- bad-fnum.da 0 Font number out of range -- bad-char.da 0 Character code out of range -- stack-ovfl.da 0 PUSH/POP stack overflow -- stack-unfl.da 0 PUSH/POP stack underflow o Limit checking tests: > limit-check/ -- chars-rules.tex 0* Multi-page test file -- char-size.mf 0 Test large character sizes -- stack.da 0 Test limit on maximum stack depth -- simple.tex 0 Test of some simple pages -- moderate.tex 0* Test of some moderate pages -- complex.tex 0* Test of some complex pages * Compliance with these tests is not required on devices which are incapable of doing so. However, the level of success must be documented. o Coordinate rounding tests: > coordinate/ -- max-drift.tex 0 Character drift tests -- rule-align.tex 0? Rule alignment tests o Non-TeX-generated DVI file tests: > non-TeX/ -- millipts.da 0 DVI units are in millipoints -------------------------------end of README---------------------------- ------------------------start of preamble/bad-id.da--------------------- % This is file dvi-test/preamble/bad-id.da % This test file was written as part of the efforts of the TeX Users % Group DVI Driver Standards Committee and is part of the DVI Driver % Standards Test Suite. The file is in the public domain and may be % freely used and copied. % Revision history: % % Version 1: Original version -- 28 Nov 90 Thomas Reid % Purpose: % % Test a driver's check for a valid DVI format code in the preamble of % a DVI file. The currently defined codes are 2 for normal DVI files % and 3 for DVI-IVD files. % Compliance level: 0 (partial compliance) % ? (full compliance) % % All drivers are expected to check for valid formats of DVI files. % At Level 0, drivers are only required to process format 2; higher % levels of the DVI Driver Standards will define requirements for % support of format 3 DVI files. % ------------------------------------------------------------------------ % Preamble: PRE 12 25400000 473628672 1000 " Test preamble/bad-id -- 1990.11.28 1300" % 12 = (invalid) DVI format code % 25400000 = (numerator of scale) 254cm/100in * 100000du/cm % 473628672 = (denomiator of scale) 7227pt/100in * 65536sp/pt % 1000 = (overall scaling of DVI units) 1000/1000 x normal size % (Distances in this file are in units of scaled points.) % ------------------------------------------------------------------------ % Body of DVI file: Page1: BOP 1 0 0 0 0 0 0 0 0 0 -1 % The text below ignores the fact that some kerning should be done. PUSH FNT_DEF1 0 0x4bf16079 655360 655360 "" "cmr10" FNT_NUM_0 "Body" W3 218453 % 6u# (from cmr10) space between words "of" W0 "DVI" W0 "file" W0 "for" W0 "dvi-test/bad-id.dvi." POP EOP % End of page [1.0.0.0.0.0.0.0.0.0] % ------------------------------------------------------------------------ % Postamble: PostStart: % record position of start of postamble POST Page1 25400000 473628672 1000 43725786 30785863 3 1 % 43725786 = (page depth) 8.9in (\vsize) + 24pt (modified \baselineskip) % 30785863 = (page width) 6.5in (\hsize) % 1 = maximum stack depth % 1 = number of pages FNT_DEF1 0 0x4bf16079 655360 655360 "" "cmr10" POST_POST PostStart 12 % End postamble and point to start of postamble % 12 = (invalid) DVI format code 0xdfdfdfdf % write out four DF bytes FILL 0xdf % Fill out to "blocksize" with DFs. -------------------------end of preamble/bad-id.da---------------------- ========================================================================= Date: Thu, 29 Nov 90 11:19:07 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: DVI driver test suite > Based on the practice of "he or she who suggests, volunteers," I have > begun a collection of files for this test suite. I will organize the > files and make them available for anonymous FTP. I am also considering > making them available through LISTSERV. (Joachim: If I do this, could > you keep a duplicate copy on the Heidelburg server for the benefit of > within EARN?) As we approve new major releases of the test suite, the > files should be moved to the "official" TeX servers. I will install a copy on the Heidelberg listserver. Tom, would you please send me the initial files (as a UNIX or VMS shar?) Also I need the DVIASM processor, I cannot find my version. (A ftp address would also be ok.) > Yes, we should include DVI files created by non-TeX DVI generators. I > do not have access to any at this time, so I will need a co-volunteer > to generate some and send them to me. I will generate some with groff, the GNU version of troff. BTW, great work! Joachim ========================================================================= Date: Thu, 29 Nov 90 18:11:27 +0100 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jan Michael Rynning Subject: Rule alignment and drift I spent yesterday morning examining the excellent postings from Tom Reid and Tom Rokicki, on rule alignment, and Tom Reid's call for comments on rule drift. I find Tom Reid's way of aligning rules in TeX very attractive, since it always gives correct alignment, except for rules which are only one pixel wide. For a rule of width w we have: <---------------------------- x ------------------------> |-------------------------------------------------------| |----------------------------------------------------|--| | |-----| <- w -> (a) (b)(c)(d) Again, we can limit a to [0..1) and x to (0..1]. Again, floor(a) = 0, and ceil(x) = 1. If floor(a) + ceil(x) < floor(b), we have a shortfall. This may be rewritten as 0 + 1 < floor(a + x - w/2), and can never occur, since floor(a + x - w/2) <= 1 for w >= 0. If floor(a) + ceil(x) > floor(b) + ceil(w), we have an overshoot. This may be rewritten as 0 + 1 > floor(a + x - w/2) + ceil(w), and can only occur for w <= 1. For w in (0..1], ceil(w) = 1, and the probability that floor(a + x - w/2) < 0, i.e. p(overshoot), is w^2/8. Now, let's see what happens if we apply Tom Rokicki's proposal to this. If floor(a + x) < floor(a + x - w/2), we have a shortfall. For w >= 0, this can never occur. If floor(a + x) > floor(a + x - w/2) + ceil(w), we have an overshoot. For w >= 0, this can never occur. Tom Rokicki's proposal solves the overshoot problem for rules which are only one pixel wide. The limit of 10 pixels proposed by Tom Rokicki should probably be made resolution dependent, just like the maxdrift. 10 pixels is a VERY wide rule on a 72 DPI device ... BTW, I think I may have found a mistake in Tom Rokicki's calculations: > floor(a) + ceil(x) != floor(a + x - y) + ceil(y) > > For arbitrary a, x, and y, this is true exactly half of the time. To > prove this, we can limit the range of |a| to [0..1) and limit the > range of |x| and |y| to (0..1] with no loss of generality (since adding > an integer to either adds the same integer to both sides). But then > floor(a) == 0, and ceil(x) == 1, and ceil(y) == 1, giving us > > 0 != floor(a + x - y) > > which is true for half of the cube. In addition, it is true for each > plane such that y is set to some arbitrary value, so the problem does not > go away if we try to limit the width of the rules to some integer multiple > of pixels, since we have no real control over absolute position (and thus > |a| and |b|.) According to my calculations floor(a + x - y) = -1 for 1/6 of the cube, 0 for 2/3 of the cube, and 1 for 1/6 of the cube. This means that the current algorithm is a little bit better than Tom Rokicki's calculations suggest. The rest of Tom Rokicki's and Tom Reid's calculations are correct, as far as I can see. As for drifting rules, is there any way to get it right, but to scan the page for characters and other rules adjacent to the endpoints of each rule? Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288 ========================================================================= Date: Thu, 29 Nov 90 15:59:37 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Test suite and DVI postambles In-Reply-To: Your message of Wed, 28 Nov 90 23:54:49 -0800 On Wed, 28 Nov 90 23:54:49 -0800 Tom Rokicki said: >Don't forget that many drivers (especially previewers) may well not ever >read the postamble . . . > >-tom This is true; such drivers should not be required to do extra work just for the sake of making sure that the DVI postamble is correct if they do not process any of it. I have changed the README file to include a note on all of the postamble tests indicating: "Drivers which do not extract any information from the postamble are exempt from these tests." ---Tom Reid ========================================================================= Date: Fri, 30 Nov 90 13:24:43 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Alignment of single pixel width rules In-Reply-To: Message of Thu, 29 Nov 90 18:11:27 +0100 from Jan, Thanks for your analysis of my and Tom Rokicki's rule alignment methods. I now see that that overshoots are possible for single pixel rules. However, based on your analysis, I see that my method can be altered to eliminate these. My original intent of extending rules halfway into perpendicular rules was to prevent any shortfall. Jan's analysis shows that, for the right and top ends, this is not necessary. Consider the following rules: <---------------------------- x ------------------------> |-------------------------------------------------------| |-------------------------------------------------------| |-----| |-----| <- w -> (a) (b) (c) From Jan Micheal Rynning: >Again, we can limit a to [0..1) and x to (0..1]. Again, floor(a) = 0, >and ceil(x) = 1. > >If floor(a) + ceil(x) < floor(b), we have a shortfall. This may be >rewritten as 0 + 1 < floor(a + x - w/2), and can never occur, since >floor(a + x - w/2) <= 1 for w >= 0. With the new technique, the w/2 term is eliminated. The new relation: 0 + 1 < floor(a + x) will be false for all a and x. Thus shortfall can never occur. >If floor(a) + ceil(x) > floor(b) + ceil(w), we have an overshoot. This >may be rewritten as 0 + 1 > floor(a + x - w/2) + ceil(w), and can only >occur for w <= 1. For w in (0..1], ceil(w) = 1, and the probability >that floor(a + x - w/2) < 0, i.e. p(overshoot), is w^2/8. Once again, the w/2 term is eliminated changing the relation to: 0 + 1 > floor(a + x) + ceil(w) which is false for all a and x and for w > 0. Thus, overshoot is prevented for any visbile perpendicular rule. The TeX code for the new technique is shown below: \newdimen\X \X=... % the left edge of the box \newdimen\Y \Y=... % the bottom edge of the box \newdimen\H \H=... % the height of the box \newdimen\W \W=... % the width of the box \newdimen\R \R=... % the thickness of the rules making up the box \newdimen\RH \RH=0.5\R % avoid problems with \R values of an \newdimen\RR \RR=2\RH % odd number of scaled points \def\P#1, #2, #3{\rlap{\kern#1 \raise#2 \hbox{#3}}} \hbox to ... {\P \X, \Y, {\hbox to 0pt{% \P -\RH, 0pt, {\vrule height \RH depth \RH width \W}% \P -\RH, \H, {\vrule height \RH depth \RH width \W}% \P -\RH, -\RH, {\vrule height \H depth 0pt width \RR}% \P \W, -\RH, {\kern-\RH \vrule height \H depth 0pt width \RR}% \P \W, \H, {\kern-\RH \vrule height \RH depth \RH width \RR}% \hss}\hss} which draws the following rules: --------------------------------------------------/// \Y + \H-- ------------------------ 2 -----------------------/5/ --------------------------------------------------/// ||| ||| ||| ||| |3| |4| ||| ||| ||| ||| +++-----------------------------------------------||| \Y + 0pt-- +++--------------------- 1 -----------------------||| +++-----------------------------------------------||| | | \X + 0pt \X + \W ---Tom Reid ========================================================================= Date: Fri, 30 Nov 90 14:44:56 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: Alignment of single pixel width rules In-Reply-To: "Thomas J. Reid"'s message of Fri, 30 Nov 90 13:24:43 CST <9011302032.AA29789@Sunburn.Stanford.EDU> Hot damn, Tom Reid's method works and works well! Congratulations, Tom, and thanks for the wonderful solution! Unfortunately, this doesn't necessary fix tables, at least not the typical form of tables that Knuth describes in The TeXbook. Tables present two difficulties: - Maxdrift correction for those cases where the rule between columns is very close to the content of the box---will TeX's push/pop stuff automatically enclose each table item, thus solving this difficulty? - Differences in alignment when \noalign{\hrule} is used (as is very commonly done.) It is this latter problem that I see most frequently. Use of the different algorithm I posted, along with careful setting of rule widths, can largely eliminate this problem---but again only with the `assistance' of the macro writer. (Note that my algorithm and Tom Reid's work fine together; because the ends of `large' rules are at the rounded positions, they will exactly abut rules they are supposed to meet.) But the naive table writer will still get unaligned tables with constructions as simple as \halign{\vrule\strut\quad\hss#\hss\quad\vrule\cr \noalign{\hrule}entry\cr\noalign{\hrule}}. For each such \noalign\hrule after the first, we can play a clever trick based on noticing that we have two rules in a sequence that both end at the same position in `sp'---and we can simply add a hack to the driver that checks that for every pair of rules that are in a sequence, if the second rule is `wide' and the pair of rules both end in the same position (in dvi units), use the pixel ending position of the first rule as the pixel ending position of the second. Note that this hack is not subsumed by my proposed pixel algorithm, and one could argue that both are needed. But this does nothing for the top rule---where such errors are usually most apparent. Another possible solution would be a *simple* change to the above halign that we could recommend everyone use to get their tables to work---something that would have the benefits of Tom Reid's technique. Something like replacing the \noalign{\hrule} by \multispan{n-1}{\hrulefill}&\cr almost works, but requires the explicit knowledge of the number of columns in the table as well as a separate column for nothing but the trailing vertical rule. Any ideas? One begins to understand why PostScript chose their simple positioning rules, which yield artifacts galore, but behave somewhat better. -tom