UKTeX V88 #25 Friday 5 August 1988 re: \shew Crudetype changes Re: Urgent submission for UK-TeX uktex v88 #24 - large TeX, and headings Transfig 1.4 Big-memory versions of TeX under VMS and Unix mail digestifiers LaserWriter II NTX METAFONT mode_def parameters (De)Compress ftp failures --------------------------------- Editor Peter Abbott I have only just discovered that cyber1 at Bradford has been replaced by cyber2. For the last three weeks or so all mail has been rejected. Back issues of UKTeX are available from [public.uktex]uktex88.nn I need a binary version of deboo for VAX/VMS. Sebastian Rahtz has provided the source but it will not compile as it complains about missing .h files. Closing date for next weeks issue is Wednesday as I shall be out of the University Thursday to Monday inclusive. Latest TeXhax in the Archive is #69 Latest TeXmag in the Archive is V2N4 --------------------------------- Date: 29-JUL-1988 17:23:47 GMT From: CHAA006@UK.AC.RHBNC.VAXB To: Info-Tex@UK.AC.ASTON.MAIL Subject: re: \shew Sender: JANET"CHAA006@UK.AC.RHBNC.VAXB" Message-Id: <222019B3_000B285C.009168DD0D679B40$33_4@UK.AC.RHBNC.VAXB> Originally-to: JANET%"Info-Tex@Aston.Mail" Mailer: Janet_Mailshr V3.0a (07-Jun-1988) Based on Barbara Beeton's solution (thanks, Barbara, and also thanks to Andy Trevorrow for another solution), I have finally produced the following :- \newtoks \toklist \def \activatespaces {\catcode `\ = \active} \def \inactivatespaces {\catcode `\ = 10\relax} \def \shew {\activatespaces \afterassignment \shewit \toklist = } \def \shewit {{\tt \expandafter \string \the \toklist}\displayit} \activatespaces% \def\displayit{{\def {}\inactivatespaces\ % \toklist=\expandafter{\expandafter\expandafter\the\toklist}% (\the\toklist)}}% \inactivatespaces \shew {\'e}, \shew {\c c} and \shew {\oe} (just checking for spaces). ** Phil. --------------------------------- Date: Fri, 29 Jul 88 17:44:57 BST From: Dr R M Damerell (RHBNC) To: abbottp@uk.ac.aston cc: damerell@uk.ac.ucl.cs.nss Subject: Crudetype changes At the Exeter conference, some bugs were reported in Crudetype. The reporters have done a lot of work to write Change files to circumvent them, but I would prefer to fix them properly in the main program. 1. Cannot generate Fortran-type carriage controls. The cause is that the constant |want_split| must be set false if |fortran| is true. Starting from the basic version of Crudetype, here is a complete list of all the changes that were needed to make Crudetype produce Fortran controls. These gave correct printed output (on VMS, with my set of test files) . 1a. In module @ fortran = true ; want_split = false ; 1b. In module @ feed_char := chr( 32) ; {space} t_feed_char := chr( 32) ; c_r_char := chr( 43) ; {plus sign} (Of course these will be wrong on a non-ASCII machine) 2. INcorrect specifications in the initial calls of |row|. In each case, an improved call of |row| should be substituted for the call in Crudetype with the same numbers. In the MATH ITALIC scheme (coding scheme 6), \imath and \jmath disappeared: row( ' Z Z Z i j LP ^ ' ,6,15,1) ; In MATH SYMBOLS, (scheme 7), the square root is too high and the delta too low, and I think the integral is also too low. row( ' [{LI_}{LI_}] Z Z Z Z ' ,7,14,1) ; 3. Variables not initialised properly. These are |D_dis| , |IM_dis| , and |thin_space|. The report said that on VMS they are initialised to zero (true), on BRAND X they get large values, which causes chaos. In theory, this is impossible. For one thing, the VMS compiler complains about un-initialised variables. Also, |D_dis| and |IM_dis| are read during the |move_right| that follows a |set_character| or |set_rule| . The |set_character| or |set_rule| ought to have assigned the correct values to these. Likewise, |thin_space| is a property of the current TEX font. It gets read during the call of |round_IM-h| that precedes any |set_character| or |set_rule| . The DVI file must select a font before it can set a character; and |change_font| assigns to |thin_space|. I tried to reproduce these bugs by assigning nonsense values to these variables; nothing happened. 4. (supposedly because of (3)) Crudetype tries to set some characters with negative coordinates (i.e. off the edge of the paper). Instead of producing an error message, Crudetype crashes in an infinite recursion. Again,it is trivial to prevent this but I would be much happier if I could reproduce it first as it may be a symptom of something else. I have not yet managed to get any of these fixes into the Aston archive. Besides bug-fixes, some people have recommended changes for aesthetic reasons. I would like to know if anybody has strong opinions for or against: 1. Suppress all terminal I/O (except error messages). 2. Get parameters from a 'command line'. (note that this is a violation of Standard Pascal). 3. Since 1 TEX page generates about 1.5 lineprinter pages, mark ends-of-pages not by form feeds but by something like ----------------------------- END OF PAGE nnn ----------------------------- 4. Use conformant arrays to clean up the code for handling character strings. (The Standard does recognise these). I will be away most of August. Mark --------------------------------- From: Julian Bradfield Date: Fri, 29 Jul 88 19:12:42-0000 Message-Id: <16856.8807291812@subnode.lfcs.ed.ac.uk> To: chaa006@uk.ac.rhbnc.vaxb, info-tex@uk.ac.aston Subject: Re: Urgent submission for UK-TeX The following slightly hairy macros allow you to determine the category code of the first letter of a control sequence name, which is all you need. \let\xa\expandafter \def\getfirst#1#2#3\endgetfirst{#2} \def\makefirst#1{% \xa\csname\xa\getfirst\string#1\endgetfirst\endcsname} \def\getcat#1{% \xa\xa\xa\xa\xa\xa\xa\catcode\xa\xa\xa\xa\xa\xa\xa`\makefirst#1} \chardef\\"5C For example, the catcode of the first letter of {\tt\\argle} is {\count255=\getcat\argle\space \the\count255}, which should have come out as 11, and that of {\tt\\@} is {\count255=\getcat\@ \the\count255}, which should have come out as 12. The reason for all that {\tt\\expandafter} hacking is to avoid having to use {\tt\\edef}, since that would get in the way in constructions like {\tt\\count255=\\getcat\\argle}. --------------------------------- Date: Sun, 31 Jul 88 18:30:02 GMT From: Sebastian Rahtz To: ABBOTTP@uk.ac.aston Subject: uktex v88 #24 - large TeX, and headings The question of a 32 bit TeX is solved for those who use the (Unix-based) C translation of TeX known as web2c; the current distribution (2.17, which I recently sent to Peter A., and which will doubtless appear soon in these columns) includes a change file which generates a wonderfully large TeX - I have not exceeded its appetites yet (such as, for instance, with 750 book citations in a recent file). In answer to Tim Bradshaw, it is fully TRIP-validated, and there are the necessary files for creating C versions of TeX, Metafont, BibTeX and most of TeXware. As has been discussed in UKTeX before, there is some question as to whether it actually generates you a faster or more efficient TeX - I can only say that a) it compiles faster b) it seems easier to build eg the 32 bit version on top of it, c) it works on System V Unix, which always had trouble with the Pascal compilation and d) it is probably mildly more portable. I got BibTeX compiled in a few minutes (as it were) on our Masscomp, where the work needed to fix the .ch file for Masscomp Pascal nasties simply hadn't got done because it was too tedious. Complicated headings: I was rather impressed by 'threepart.sty' in the LaTeX-style collection (I forget the directory name at Aston but its there), which makes the multi-part header and footer creation rather easier. I haven't tried putting in multi-line ones, but surely a tabular inside a minipage would not break it? Sebastian Rahtz +++Editor - Most of the files are complete and this should be available shortly +++ --------------------------------- Date: Thu, 28 Jul 88 13:10:14 GMT From: Sebastian Rahtz To: info-tex@uk.ac.aston.mail Subject: Transfig 1.4 I am sending under seperate cover a set of files which, when joined end to end, make a Unix 'shar' archive of Micah Beck's 'transfig' package, version 1.4. This is a set of utilities to do conversion in various directions between Fig codes, 'pic' code, PostScript LaTeX picture and 'pictex'. The aim is producing portable figures in TeX which don't require your recipient to have the same obscure package as you. If you use Fig or Pic, you want this stuff! sebastian rahtz +++Editor - It is available in aston.spock::[public.transfig] +++ --------------------------------- Date: 2 Aug 1988 12:53:15-WET Subject: Big-memory versions of TeX under VMS and Unix From: alien To: info-tex@uk.ac.aston.mail A number of people have been asking recently whether it is possible for TeX to have a memory size >64Kbytes. The answer is, of course, yes. The problem has been solved under both Unix and VMS: Unix sites should use Web2c, which also gives improvements in execution times, while VMS sites could use my change file: look at my articles in TUGboat vol 8 nos 2 & 3 , particularly at the foot of the first column of p272 (in no 3). **Adrian. Adrian F. Clark JANET: alien@uk.ac.essex.ese ARPA: alien%uk.ac.essex.ese@cs.ucl.ac.uk BITNET: alien%uk.ac.essex.ese@ac.uk Smail: Dept. of Electronic Systems Engineering, Essex University, Wivenhoe Park, Colchester, Essex C04 3SQ, U. K. Phone: (+44) 206-872432 (direct) +++Editor - For which version is the change file and please may I have a copy for the archive (preferably for 2.93) +++ --------------------------------- Received: from hci by brahma.cs.hw.ac.uk; Thu, 28 Jul 88 16:46:31 BST Received: from tamdhu.hci.hw.ac.uk by glenlivet.hci.hw.ac.uk; Thu, 28 Jul 88 10:18:12 BST From: Gordon Howell Date: Thu, 28 Jul 88 10:54:41 BST Message-Id: <26104.8807280954@tamdhu.hci.hw.ac.uk> To: ABBOTTP@UK.AC.ASTON In-Reply-To: ABBOTTP@UK.AC.ASTON's message of 12-JUL-1988 16:36:49 GMT <4079.8807121539@brahma.cs.hw.ac.uk> Subject: mail digestifiers > > `Proposed Standard for Message Encapsulation' I seem to have opened a can of worms on this issue. I am starting a digest here, and decided it was high time for a better digestifier... Turns out that this is one piece of software that everyone writes for themselves, and I am now trying to put together some definitive package for GNU emacs. (I am in no great hurry, since I have 'fixed' my undigestifier to cope with several formats) It looks like you are on a VMS system; thus I don't know if a GNUemacs package would help you (GNU runs under VMS, but last time I used it there was no 'rmail' interface) Also, I didn't realize there was a written standard for encapsulation. I always thought it was 'de-facto'... Could you send me this text? thanks, Gordon Howell gordon@hci.hw.ac.uk Scottish Centre for Human Computer Interaction Edinburgh, Scotland +++ Editor - Please can someone send Gordon the relevant document as I cannot remember on which system it is stored. Thanks +++ --------------------------------- Date: Tue, 2 Aug 88 17:38:09 GMT From: Sebastian Rahtz To: info-tex@uk.ac.aston.mail Subject: LaserWriter II NTX People considering upgrading their LaserWriters may be interested to hear that we just got an LW IINTX with hard disk, and all performed happily. A report on TeXhax that the MacDraw prolog file failed scared me for a while but it is just the usual problem of Apple changing the prolog every 2 weeks. The hard disk is a boon - one can download new Adobe fonts onto it, and they are recognised automatically; next step is to download CMR onto there for faster CMR TeXing (if anyone would want to!) Q. Has anyone got a Canon SX engine like the LWII and worked out Metafont definitions for it? Its a writewhite job, so the old LW definitions are probably not the best that can be achieved. I dont feel competent to experiment so if anyone has done the work, cou;d they publicise it? Sebastian --------------------------------- Date: THU, 04 AUG 88 16:06:25 GMT From: C20222 @ UK.AC.PLYMOUTH.PRIME-B To: info-tex @ UK.AC.ASTON Sent by: Jon Warbrick Plymouth PolyTeXnic Computing Service. Does anyone know acceptable METAFONT mode_def parameters for either an HP LaserJet series 2 (Canon SX print engine) or a Dataproducts LZR2665 (Toshiba print engine, model number unknown)? Please let me know if you do, it would save me a lot of work. Jon. --------------------------------- Date: 4 Aug 1988 12:06:53-WET From: alien To: abbottp@uk.ac.aston.mail Peter, I've had a play with Martin Minnow's versions of compress, the software you got from the States recently. It looks as though I can compress files (i.e., the program doesn't crash), but I can't then decompress them. The details are as follows: There are two modes of compressing files, `VMS private' (which retains the record structure) and `export' (compatible with Unix compress 4.0). We obviously want to use `export' mode for the mail server. Well, I can compress files in export mode without any trouble; the output file then has STREAM_LF record type. I also tried using the VMS private mode. I shouldn't: it failed. It said that it couldn't open the input file! (I also got this from the decompression program; see below.) When I tried to decompress the export-format compressed file, telling the decompression program that the file is in export format, it crashes (access violation---pretty spectacular) when trying to execute `GET(&instream)' at line 1991 of LZDCM1.C. Yuk. And when I tell it the compressed file is in VMS private format (even tho' it isn't), it fails with `input file not found'. I investigated this and found that its file-opening routine, fdl_open, returns `file not found' if the input file has STREAM_LF record type!! (This is my greatest criticism of C: the error returns from library functions are lousy.) What makes everything particularly galling is that the programs work perfectly well under 4.2bsd Unix. **Adrian. +++ Editor - I have parts 1 and 2 of the recent infovax posting for (De)Compress off the VAX SIG tape but need part 3. Otherwise can anyone else suggest what to do. +++ --------------------------------- Received: from odin.cs.hw.ac.uk (odin) by brahma.cs.hw.ac.uk; Fri, 5 Aug 88 12:53:46 BST From: Ian Crorie Date: Fri, 5 Aug 88 12:51:08 BST Message-Id: <13945.8808051151@odin.cs.hw.ac.uk> To: postmaster@uk.ac.aston.spock Subject: ftp failures Perhaps you can help me or pass this to someone who may be able to. A user here wants to ftp down some font files for tex. They are listed as being there and we have been able to copy down large numbers of other tex files without problems. However, we keep getting the messages below. Any ideas? I have tried specifying that these are binary transfers but to no avail. The transfer of file /u1/staff/idc/tmp/aston/tex/amsfonts/pxl300/mcyb10.1500pxl from host uk.ac.aston.spock over janet failed. The reason given by the remote host was: Invalid value in command: - filename "[public.tex.amsfonts.pxl300]mcyb10.1500pxl" record format incompatible with transfer code. VAX/VMS FTP (80) Version 4.3a. +++Editor - The file you have tried is NOT stream_lf and I can find no reason why it will not work. You could try using mail to get the file. Send a mail message to texserver@aston and in the body of the message start a line with --- on the next line put idc@uk.ac.hw.cs (name@address) and the following line the word help. e.g --- idc@uk.ac.aston.spock help As soon as we can get access from our UNIX system we will try here at Aston. +++ --------------------------------- !! !! Files of interest [public]000aston.readme !! [public]000directory.list !! [public]000directory_dates.list !! [public]000directory.size !! [public]000last30days.files !! !! Editor - I have a tape labelled TeX 2.9 LaTeX 2.09 Metafont 1.3 !! Unix 4.2/3BSD VAX SUN 2/3 Pyramid Seqeunt SYS V: 3B2 Tar 1600 bpi blocked !! 20 1 file dated 26 may 1988 (from washington.edu). !! !! I have the facilty to copy this tape for anyone who sends the following !! !! 1 2400 tape with return labels AND RETURN postage. !! !! Send to !! !! P Abbott !! Computing Service !! Aston University !! Aston Triangle !! Birmingham B4 7ET !! !! A VMS backup of the archive requires 2 (two ) 2400' tapes at 6250bpi. !! Remaining details as above. !! !! Replies/submissions to info-tex@uk.ac.aston please !! distribution changes to info-tex-request@uk.ac.aston please !! !! end of issue