TeXhax Digest Monday, October 17, 1988 Volume 88 : Issue 91 Moderator: Malcolm Brown Today's Topics: Re: Question (UNIX, typesetter) TeX dumps core! Further on TeX dumps core Re: Problems with journals that accept TeX Re: TeXhax Digest V88 #88 Diffs to dvips Re: TeXhax Digest V88 #88 (LaTeX notes) Re: Bug in ctex.ch (web2c 2.2)? computer modern for aps typesetter TP4 Version of TeX Laserprinter Query Re: BibTeX sorting Extending TeX's alphabet from 128 to 256 characters Full page bitmap of dvi file ---------------------------------------------------------------------- Date: Mon, 10 Oct 88 16:23:13 CDT From: William LeFebvre Subject: Re: Question (UNIX, typesetter) > Apparently the order of the bytes is different in a VMS and a UNIX > system. What matters is the hardware, not the operating system. Nonetheless, a machine's byte ordering has NO BEARING on a dvi file. The dvi format specifically defines the byte ordering of binary numbers. Thus, a dvi file is portable between any two machines. What may be tripping you up in this case is different block sizes. Unix doesn't care about blocking, but VMS usually does. You might want to try the following: before putting the dvi file on tape, make sure that its length is a multiple of 1024. If it is not, pad it out to the nearest multiple of 1024. Do this by adding a sufficient number of bytes to the file and make each byte equal to the octal value "337" (hex "DF"). This is the dvi padding-byte value. You will probably need to write a C program to do this, but it's an easy program to write. It might help if the typesetter people would tell you EXACTLY what format tape they need (record size and number of records in a block---or just block size would be helpful). If they say something like "block size N, unformatted records", then pad the file to a multiple of N (as described above) and make the tape with "dd bs=N". William LeFebvre Department of Computer Science Rice University ------------------------------ From: munnari!goanna.oz.au!isaac@uunet.UU.NET (Isaac Balbin) Subject: TeX dumps core! Date: Tue, 11 Oct 88 17:59:37 +1000 The unspeakable? --- or is this just another example of the balbin triangle? Using LaTeX 2.09 (Apr 88), and TeX , C version 2.93, I get a floating point exception & core dump (from vlistout(),3 of them preceded by a zshipout) on a particular file. Interestingly, if I tex this file (as \input) _after_ another file (also \input) there is no core dump. The core dump occurs whilst processing pap.bbl although I don't think that has much to do with it? I use bibtex 0.99c (the C version). Of even more interest? is that it dumps core using CommonTeX as well! Whatsmore, in the same routine (suprise) (vlistout). Of even more interest? it doesn't dump core on an old version of TeX in pascal on a Sun 3. I think the operative thing here is the Sun 3 as distinct from the architecture I am running it on which is an Encore under System V (although the latter is irrelevant). So, who is interested in such manifestations? Is there anyone out there who would like to try latexing the file on their architecture and seeing if the same occurs? Has this occured to anyone else? What hidden gottcha's should I check for? Thanks, in advance, for any help Isaac Balbin Department of Computer Science, ACSnet: isaac@goanna.oz RMIT, GPO BOX 2476 V, ARPA:isaac%goanna.oz.au@uunet.uu.net Melbourne, 3001 CSNET: isaac%goanna.oz.au@australia AUSTRALIA UUCP: ...!uunet!goanna.oz.au!isaac %%% Part Two of this tale follows immediately.... ------------------------------ From: munnari!goanna.oz.au!isaac@uunet.UU.NET (Isaac Balbin) Subject: Further on TeX dumps core Date: Tue, 11 Oct 88 18:31:38 +1000 Further to my previous message, I think I may have discovered a cause (it isn't a reason) for the core dump. I was trying to cajole LaTeX, in a general way, to never break pages whilst handling one of my many tabbing environments. These were not figures or tables, just little bits of code. Now, I know there are probably other ways .... I was looking for something short and sweet which would always work. (if you have any sure fire method you want to tell me about ... go for it!) So, I merely did the following ... \filbreak{ \begin{tabbing} ...... \end{tabbing} } Now this works fine ... however if you have two filbreaks on a page (I am guessing) something gets screwy. I mentioned that when I latex something before the troublesome file the core dump disappears. True enough, but the output which is not what one would expect indicates that the second filbreak caused a whole lot of space to be left just before the references section even though that was not required. Okay, it should be obvious by now that I am not TeXpert but before you sharpen your claws, and propose a different LaTeX based solution which you swear will always work, do you think that a core dump is justified? Or is that just a C compiler bug in the encore C compiler (quite possible) (I should try compiling with gcc). Thanks for your time ... PS. When I removed filbreaks --- no core dump. ------------------------------ Date: Mon, 10 Oct 88 16:36:09 CDT From: William LeFebvre Subject: Re: Problems with journals that accept TeX > ... journals tend to wind up with two kinds of articles with totally > different outlook. This is ugly....It may be acceptable (or rather, it > is common practise) for rapid dissemination proceedings, it just won't > do for regular scientific publication. Agreed! Journals should take their time: quality is more important than speed for a journal. Clearly what must happen, and what may happen in the not-to-distant- future, is that the old typesetters (the people, that is) must be reeducated in the area of electronic typesetting (or make way for those who are). This is a brand new field (newer even than computer science)---it will require its own specialists and it will take awhile to mature. But I see this as the way of the future. Right now we have people who specialize in conventional typesetting. They know the right way to place text on a page: where to put in extra space, where to squeeze characters together, where to break lines and pages, etc. What we need to have in the future is people with this same knowledge and skill who use TeX (or some yet-to-be-invented successor) as their typesetting tool rather than the current conventional typesetting hardware. Where these journals are going wrong is in the assumption that TeX will eliminate the need for a typesetter. It doesn't: it is just providing a more powerful tool for the typesetter to use. Weak analogy: mainstream typesetting --> machine language; TeX --> high-level (compiled) language. The introduction of Fortran caused many negative feelings among the die-hard assembly/machine language programmers. I see something similar happening in typesetting with the introduction of TeX. This will all just take time to develop. William LeFebvre Department of Computer Science Rice University ------------------------------ Date: Mon, 10 Oct 88 18:22:50 EDT From: zwicky@pterodactyl.cis.ohio-state.edu (Elizabeth D. Zwicky) Subject: Re: TeXhax Digest V88 #88 About dvi2ps on a typesetter. No, it won't always work. Yes, PostScript is a standard. No, it isn't necessarily the environment on the typesetter. dvi2ps (in at least some of its versions) contains LaserWriter specific code - sort of like all those C programs that dereference a null pointer because they were written on Vaxen. In particular, one that we used to run used the page type "note" which not all printers have. There is an Appendix to the Red Book (in some editions) which talks about the LaserWriter. Using any PostScript primitives mentioned therein makes your code non-portable, which as we all know is a sin. A more modern dvi2ps should solve the problem. Elizabeth Zwicky ------------------------------ Date: Mon, 10 Oct 88 17:00:07 cdt Subject: Diffs to dvips From: grunwald@m.cs.uiuc.edu (Dirk Grunwald) The following context diffs to the version of `dvips' that I got from the Univ. of Washington (june.cs.washington.edu) allow you to use `dvips' on UltraScript printers. These differences are relative to the diffs I posted a week ago to include ``psfig'' specials in dvips. PostScript hacking courtesy of Gorden Skorstad. Dirk Grunwald Univ. of Illinois grunwald@m.cs.uiuc.edu #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # download.diff # structures.diff # tex.lpro.diff # This archive created: Mon Oct 10 16:57:11 1988 export PATH; PATH=/bin:$PATH if test -f 'download.diff' then echo shar: will not over-write existing file "'download.diff'" else cat << \SHAR_EOF > 'download.diff' *** /tmp/,RCSt1005859 Mon Oct 10 16:54:47 1988 --- download.c Mon Oct 10 14:28:04 1988 *************** *** 177,181 cc++ ; } } } } --- 177,182 ----- cc++ ; } } + cmdout("dfend"); } } SHAR_EOF fi # end of overwriting check if test -f 'structures.diff' then echo shar: will not over-write existing file "'structures.diff'" else cat << \SHAR_EOF > 'structures.diff' *** /tmp/,RCSt1006792 Mon Oct 10 16:55:20 1988 --- structures.h Mon Oct 10 16:48:49 1988 *************** *** 21,26 * Constants, used to expand or decrease the capacity of this program. */ #define STRINGSIZE (3141) /* maximum number of strings in program */ #define SWMEM (100000) /* font memory in smartwriter */ #define RASTERCHUNK (8192) /* size of chunk of raster */ #define MINCHUNK (256) /* minimum size char to get own raster */ --- 21,30 ----- * Constants, used to expand or decrease the capacity of this program. */ #define STRINGSIZE (3141) /* maximum number of strings in program */ + + #if defined(ScriptPrinter) || defined(UltraScript) + #define SWMEM (409776) /* font memory in ScriptPrinter */ + #else #define SWMEM (100000) /* font memory in smartwriter */ #endif *************** *** 22,27 */ #define STRINGSIZE (3141) /* maximum number of strings in program */ #define SWMEM (100000) /* font memory in smartwriter */ #define RASTERCHUNK (8192) /* size of chunk of raster */ #define MINCHUNK (256) /* minimum size char to get own raster */ #define MAXDRIFT (3) /* maximum drift in pixels */ --- 26,33 ----- #define SWMEM (409776) /* font memory in ScriptPrinter */ #else #define SWMEM (100000) /* font memory in smartwriter */ + #endif + #define RASTERCHUNK (8192) /* size of chunk of raster */ #define MINCHUNK (256) /* minimum size char to get own raster */ #define MAXDRIFT (3) /* maximum drift in pixels */ SHAR_EOF fi # end of overwriting check if test -f 'tex.lpro.diff' then echo shar: will not over-write existing file "'tex.lpro.diff'" else cat << \SHAR_EOF > 'tex.lpro.diff' *** /tmp/,RCSt1006540 Mon Oct 10 16:55:02 1988 --- tex.lpro Mon Oct 10 16:50:47 1988 *************** *** 1,3 % a start (Ha!) at a TeX mode for PostScript. % The following defines procedures assumed and used by program "dvi2ps" % and must be downloaded or sent as a header file for all TeX jobs. --- 1,4 ----- + %! % a start (Ha!) at a TeX mode for PostScript. % The following defines procedures assumed and used by program "dvi2ps" % and must be downloaded or sent as a header file for all TeX jobs. *************** *** 100,106 /Encoding 128 array def 0 1 127 {Encoding exch /.undef put} for end ! newname newname load definefont setfont fontname { /foo setfont } % dummy macro to be filled in 2 array copy cvx def % have to allocate a new one fontname load % now we change it --- 101,110 ----- /Encoding 128 array def 0 1 127 {Encoding exch /.undef put} for end ! % DON'T "DEFINEFONT" HERE!! DEFINED FONT DICTIONARIES ! % HAVE READ-ONLY ACCESS, THUS MAKING "dc"s JOB OF ! % BITMAP LOADING ILLEGAL. - G.Skorstad, 10/88 ! % newname newname load definefont setfont fontname { /foo setfont } % dummy macro to be filled in 2 array copy cvx def % have to allocate a new one fontname load % now we change it *************** *** 108,113 cvn cvx put % and stick it in } def % the following is the only character builder we need. it looks up the % char data in the BitMaps array, and paints the character if possible. % char data -- a bitmap descriptor -- is an array of length 6, of --- 112,124 ----- cvn cvx put % and stick it in } def + % End one font dictionary definition. This should + % be called after each "df" font bitmap block. + % - G.Skorstad, 10/88 + /dfend + {newname newname load definefont setfont} + def + % the following is the only character builder we need. it looks up the % char data in the BitMaps array, and paints the character if possible. % char data -- a bitmap descriptor -- is an array of length 6, of *************** *** 130,139 }if restore } def ! % in the following, the font-cacheing mechanism requires that ! % a name unique in the particular font be generated ! ! /dc % char-data ch dc - -- define a new character bitmap in current font { /ch-code exch def % ++oystr 12-Feb-86++ dup 0 get --- 141,151 ----- }if restore } def ! ! % in the following, the font-cacheing mechanism requires that ! % a name unique in the particular font be generated ! % char-data = the long array preceding each "dc" call. ! /dc { /ch-code exch def dup 0 get % ++oystr 12-Feb-86++ length 2 lt *************** *** 135,142 /dc % char-data ch dc - -- define a new character bitmap in current font { /ch-code exch def ! % ++oystr 12-Feb-86++ ! dup 0 get length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if --- 147,153 ----- % char-data = the long array preceding each "dc" call. /dc { /ch-code exch def ! dup 0 get % ++oystr 12-Feb-86++ length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if *************** *** 138,144 % ++oystr 12-Feb-86++ dup 0 get length 2 lt ! { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if % --oystr 12-Feb-86-- /ch-data exch def --- 149,155 ----- { /ch-code exch def dup 0 get % ++oystr 12-Feb-86++ length 2 lt ! { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if /ch-data exch def % --oystr 12-Feb-86-- % PUT CHAR DATA INTO WORKING FONT DICTIONARY. *************** *** 140,150 length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if ! % --oystr 12-Feb-86-- ! /ch-data exch def ! currentfont /BitMaps get ch-code ch-data put ! currentfont /Encoding get ch-code ! dup ( ) cvs cvn % generate a unique name simply from the character code put } def --- 151,163 ----- length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if ! /ch-data exch def % --oystr 12-Feb-86-- ! % PUT CHAR DATA INTO WORKING FONT DICTIONARY. ! % -G.Skorstad, 10/88 ! newname load /BitMaps get ch-code ch-data put ! newname load /Encoding get ch-code ! dup ( ) cvs cvn % generate a unique name simply ! % from the character code put } def SHAR_EOF fi # end of overwriting check # End of shell archive exit 0 ------------------------------ Date: Mon, 10 Oct 88 16:13:53 PDT From: lamport@src.dec.com (Leslie Lamport) Subject: Re: TeXhax Digest V88 #88 (LaTeX notes) Bernie Cosell writes: It seems to me that what LaTeX should have is four families (roman, sanserif, typewriter and smallcaps) and two style attributes (italic and bold). The families should _switch_ leaving the prevailing style alone; the styles should *stack* leaving the prevailing family and any other styles alone. If I'm italic, and I enter a \bf region, I should expect to now be in bold-italic. Would this be crazy? Would it be an improvement? Would it be hard to do? What he wants is quite reasonable, but impractical. The problem is that this would involve a large number of fonts--roughly four times as many as now used--most of which do not exist. G.J. Stemerdink writes I can't find in the LaTeX manual any reference to the rule that one should not use numbers in command names. Since the manual says in at least three places that a command name consists of a `\' followed by either a single nonletter or a string of letters, I can only conclude that Mr. Stemerdink is unaware that "letter" refers to one of the 26 characters "a"-"z" and their uppercase counterparts, and does not include the digits "0"-"9". I suppose this type of misunderstanding is unavoidable when a manual is read by a non-native speaker. However, I would have thought that lines 3-6 on page 16 were sufficiently unambiguous. Leslie Lamport ------------------------------ From: ekrell@ulysses.att.com Date: Mon, 10 Oct 88 19:58:22 EDT Subject: Re: Bug in ctex.ch (web2c 2.2)? That problem was fixed a long time ago. You have an old version of web2c. ------------------------------ Date: Mon, 10 Oct 88 17:18:46 pdt From: rusty%garnet.Berkeley.EDU@violet.berkeley.edu Subject: computer modern for aps typesetter On score, there is a directory . We have an aps typesetter. How can I get these fonts into/onto our typesetter? ------------------------------ Date: Tue, 11 Oct 88 10:07:51 GMT From: Wayne Sullivan Subject: TP4 Version of TeX Progress report on a version of TeX for MSDOS PC's using Turbo Pascal 4.0: Test versions of this program are now being used locally and by some people who offered to help with the work. The INITEX EXE file is about 195k, while the TEX EXE is about 178k. On a 640k PC, this leaves about 75k 4 byte memory words for mem and font_info, minus the memory used by resident utilities. In an effort to match the speed of commercial programs, considerable use of inline code has been made, so that there are probably numerous sneaky bugs remaining, but the TRIP.LOG correesponds exactly to what it should except for memory allocation, which has been slightly modified in the TP4 version. The program will not be available for general release until the NEW TRIP test has been checked, the output files for which are not yet to hand (hint to BB). The idea is to make the TeX and INITEX exe files generally available gratis. It is planned to make the documentation into a book, which would come with the change file and the special version of TANGLE which breaks the Pascal file into units suitable for TP4. It is possible to be able to release the test version now because of very considerable help from Peter Breitenlohner. Also Peter Sawatzki contributed some useful ideas. Wayne Sullivan ------------------------------ Date: Tue, 11 Oct 88 08:55:35 ADT From: "Steven Osborne - Computer Science UNB" Subject: Laserprinter Query Does anyone out there know the whereabouts of any 600 dpi Laserprinters? I would like to know the manufacturer and the model number if you know of any. Thanks. Sincerely Yours Steven Osborne Hardware Systems Specialist School of Computer Science University of New Brunswick P.O. Box 4400 Fredericton, NB Canada E3B 5A3 (Bitnet) ------------------------------ Date: Tue 11 Oct 88 07:55:54-PDT From: Oren Patashnik Subject: Re: BibTeX sorting > Subject: BibTeX Sorting > From: Rodney Topor > I have just started using BibTeX. With styles plain and abbrv, it > seems to sort entries alphabetically by author. Entries for the same > author seem to be sorted randomly. Is there any way to sort entries > with the same author by year (without editing the bbl file)? Yes. The old `plain' and `abbrv' styles (version 0.98) sorted by author then title. The new versions sort by author, then year, then title. So the answer is: Use the new versions (you'll need the new version (0.99) of BibTeX, too). Ask your system's LaTeX installer to get the new versions, and be sure that documentation is included. (The "BibTeXing" document is the most important.) > Similarly, with style alpha, entries are sorted by the generated label. > This can separate entries for the same author, which looks wrong. I agree that it's wrong, but it's even worse to not sort by label first. Here's an argument from an earlier TeXhax message I sent: This label-first alphabetizing scheme is best (for `alpha') for two reasons. First, it's the label that a reader uses to find the reference in the reference list, so the entries should be alphabetized first by label. (Otherwise, for example, a reader might have to search all the `A' entries to find [AB87] (if, for instance, the `AB' comes from authors Fred Aza and Joe Bloe); this wouldn't be so hard for a 7-entry reference list, but it would be quite annoying for a 50-page bibliography that has three pages of `A' listings.) And second, if you have entries for [AB87a] and [AB87b], you'd like them to appear together; but by the author-first scheme, they might be separated (and perhaps by several pages) in the 50-page bibliography. The problem you bring up is one of the reasons I prefer the `plain' style to the `alpha' (or any other author-date) style. There are other, more important reasons that I won't address here. > Is there any way to sort entries by author and year with style alpha? Yes, but without modifying `alpha' it's somewhat messy. If you really don't want to sort label first, you should, instead, modify `alpha' (it's a fairly easy change if you're familiar with the .BST language), but be sure to call it something other than `alpha'. --Oren Patashnik (BibTeX implementor) ------------------------------ Date: 11 Oct 88 17:00:59 EDT From: "STEFANOS MANGANARIS" Subject: Extending TeX's alphabet from 128 to 256 characters Hello TeX friends ! Here in Greece we'd like to have a TeX system that can handle mixed greek and latin text. Besides greek fonts (that we hope to build via MF) and the problem of hyphenation in greek text (that we have almost solved), we need a modified version of TeX that can handle easily not just 128 characters but 256 instead. (We don't want to use the \char feature since we want to keep TeX interactive, with HELPFUL error messages) I can imagine that what we want implies major modifications not just in the TeX program but also in others, like tangle and patgen. For example we have to shift integers that represent strings from the pool up by 128, to make room for the new characters... Has anybody ever tried extending TeX's alphabet? Could you suggest any other problems that have to be considered ? I would very much apreciate any help! Bye bye, > Stefanos Manganaris BITNET: SMANG@GRPATVX1 < > Computer Technology Institute UUCP: ...!mcvax!ermhs!stefanos < > Patras Greece < ------------------------------ Date: Tue, 11 Oct 88 13:43:43 EDT From: ajb%cornea.mitre.org@gateway.mitre.org Subject: Full page bitmap of dvi file In response to my question regarding how to produce a full page bitmap image of a dvi file, I received several very useful responses. Thank you to everyone who responded. Following are extracts from the responses. Alan J Broder ajb@mitre.arpa Image Processing Technology Center > From: "DOUG MCDONALD" > > Your job is essentially trivial. There are public domain programs > that almost do that. The Nelson Beebe dvi drivers and my derivative, > a screen driver, generate bitmaps in memory. A 300 dpi bitmap of > a normal sized page is only 1 megabyte. You should look at my DVIVGA > driver and Beebe's okidata printer driver (which has a serious bug > in the actual drawing routine - use mine). Starting from mine, > you must change the defines for size and then hack out the interactive > user input and write out the bitmap - then put back in the input > for which page you want. ftp my stuff from b.scs.uiuc.edu (but you > need an IBM-PC to unpack it) (default anon ftp directory) and > Beebe's from science.utah.edu directory aps:. > Doug McDonald (mcdonald@uiucuxe or mcdonald@uxe.cso.uiuc.edu > not the b.scs.uiuc.edu) > > > From: Ken Yap > > Sure, no reason why not. A couple of Nelson Beebe's drivers generate > bitmaps. However a back of the envelope calculation will show you that > a 300 dpi page will take: 7.5x10x300x300/8 bits which is roughly 1 Mb > per page. I hope you have a lot of free disk space for a document. > > Secondly why not do the antialiasing on a per-character basis? Save the > pixmaps for each character. This should speed things up a lot for no > loss in quality. One previewer I know of, dvipage, does grey scale > bitmaps. I think it was posted to comp.sources.unix. > > Ken > > > From: rcb@rti.rti.org (Randy Buckland) > > If you can't find exactly what you are looking for, you might > want to take the code for my DVI previewer for VMS vaxstations and modify > it. It generates a bitmap of the current page and then displays it on the > screen. It can also generate for any resolution you have the fonts generated > for. It would be relatively easy to remove the UIS display code and just > dump the bitmap to a file or hand it off to your display device. > > It can be gotten by anonymous ftp from argon.rti.org [128.109.139.64] > > > From: aslam@p.cs.uiuc.edu (Sohail Aslam) > > You may want to check out the Utah Raster kit. One of the filters is > `dvi2rle'. Once in the RLE format, your can apply numerous other > filters. Here is the blurb. ... > > > From: spencer@crim.eecs.umich.edu (Spencer W. Thomas) > > I have a program (part of the Utah Raster Toolkit) that converts DVI > output into RLE (the URT file format). The output resolution is any > integer divisor of 300DPI (e.g., 300, 150, 100, 75, ...), with > anti-aliasing at the lower resolutions. > > The URT is available from cs.utah.edu (in pub/toolkit-2.0.tar.Z, or > pub/toolkit-2.0.tar.[123].Z) by anonymous FTP (be sure to select BINARY > mode). If you get the [123] files, the third file just has test > images in it. > ------------------------------ %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L % to subscribe %%% %%% All others: send mail to %%% texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% %%% All submissions to: texhax@score.stanford.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% [SCORE.STANFORD.EDU]TEXHAXnn.yy %%% nn = issue number %%% yy = last two digits of current year %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------