UKTeX V88 #20 Friday 1 July 1988 TeX & LaTeX DVItoLN03 PK-format files with LN03 and LN03+ on VMS DosTeX: DEBOO without the RSX dependency Agfa P400 and P3400PS printers Centralised UK archive server --------------------------------- Editor Peter Abbott Now that the archive contains TeX 2.9 and the diffs for 2.92 has anyone the change file for VMS. Better still has anyone produced a new VMS version that I can get hold of for use here at Aston. Latest TeXhax in the Archive is #59 Latest TeXmag in the Archive is V2N4 --------------------------------- Via: dcs.leeds.ac.uk (csvax1.ARPA); Mon, 27 Jun 88 09:37:24 GMT From: D L Harkess Date: Mon, 27 Jun 88 09:36:52 GMT Message-Id: <9175.8806270936@dcs.leeds.ac.uk> To: abbott@uk.ac.aston Subject: TeX & LaTeX Cc: david@uk.ac.leeds.dcs I would be extremely grateful if you could point me in the direction of a description of the relationship between TeX and LaTeX: the more the merrier. Many thanks, David Harkess _________________________________________________________________________ | David Harkess | david@leeds.dcs.ac.uk Dept of Computer Studies | University of Leeds | Tel: 0532 335453 LEEDS LS2 9JT | TELEX 556473 A/B UNILDS 9 England | Fax 336017 ________________________________|________________________________________ --------------------------------- The subgroup public.drivers.ukln03 contains the following DVItoLN03 ========= This directory contains the following files: AAAREADME.TXT - the file you are reading DVILN03.BARE - a simplified version of DVILN03.TEX (see below) DVILN03.LN3 - file ready to be COPYed to your LN03 DVILN03.TEX - the RMCS ``local guide'' for DVItoLN03 DVITOLN03.CH - a change file for DVItoLN03, currently empty! DVITOLN03.CLD - VMS command language definition for the DVILN03 command DVITOLN03.WEB - the WEB source of DVItoLN03 LOCAL_GUIDES.BIB - a BibTeX database used by RMCS GRAPHICS.STY - a local LaTeX style file for graphics inserts OPENCLOSE.SIX - a Sixel dump of the screen of a terminal, scaled 2:1 OPENCLOSE.SMALL - the same dump, but scaled 1:1 RMCS.STY - a local LaTeX style file for some macros used All the files, apart from this one and those named DVITOLN03 are only concerned with producing the local guide, and will need local modification -- for example, the local guide uses a macro from RMCS.STY which invokes the coat-of-arms of the RMCS on the title page! You may care to produce a copy of our local guide by simply COPYing the file DVILN03.LN3 to YOUR LN03. Please note that this file includes LOTS of eight- bit characters, so you may need to fetch it again in binary mode if your Janet connection has stripped off the 8th bit. If your LN03 is set up as a printer queue (as the local guide recommends), the safest bet is to PRINT it /PASSALL until you've found out how to set up the queue. However, the real meat is in DVITOLN03.WEB; this is a WEB version of a DVI-to... driver for the DEC LN03/LN03-Plus laser printers. At present, it is only capable of working with expanded pixel files (somewhat old hat, I know, but it works!) but has the advantage over certain other DVItoLN03 programs of: i) It IS written in WEB, as opposed to C and other such kludgy languages ii) It downloads to the LN03's font memory the rasters for only those characters actually used in the document. As such, it does not run out of font memory just because you've used a few characters from each of a large number of different fonts iii) It HAS a capacity for SIMPLE graphics inclusions. These have to be in a format the LN03 understands (DEC sixels), and are copied verbatim into the output file generated. iv) It works with landscape and portrait orientations v) It makes use of the ``proper'' VAX/VMS DCL interface for commands The program makes a number of assumptions: i) The .TFM files will be found in the directory to which the VMS logical name TEX$FONTS points ii) The pixel files have the file type .PXL and are stored in different directories for each magnification; these directories are named [1500], [1643], [1800], etc and all lie in the rooted file directory to which the concealed ``device'' logical name TEX$PXL_ROOT: points. So, for example, cmr10 \magstep 3 will be expected to be found as TEX$PXL_ROOT:[2592]CMR10.PXL iii) The LN03 has sufficient font memory --- for most meaningful documents you will need one RAM cartidge (part number LN03X-CR); the program WILL work with just the RAM in the basic printer, but you will probably have to restrict yourself to printing documents 3--4 pages at a time: very messy! Everything else is explained, I hope, in the local guide. Since the distributed version of this can't be processed until you've got a working DVItoLN03, the file DVILN03.BARE is a stripped down version of the guide, which doesn't (I think) use any of the features peculiar to DVItoLN03. Known deficiencies i) The program cannot reproduce ``large'' characters; the LN03 itself has a (somewhat arbitrary) restriction in that the raster of any single character may not violate the following inequality: 2\times\lciel cols/2 \rceil \times \lceil rows/8 \rceil \le 5700 This means that no character from CMINCH (except for the letter ``I'') may be printed. Any such large character is treated as if it were an ``invisible'' character of the correct width. It is hoped that future development will be able to ``print'' each such character (as a sixel bitmap) wherever it is used. (Note: The program used to blindly download all such oversized characters, and the user guide still refers to this. If such a resulting .LN3 file is downloaded to the printer, the LN03-Plus reports ``Error in downloaded font''; subsequent attempts to print characters from that font (which may well contain characters taken from other TeX fonts also) will just produce blank space. With the ``ordinary'' LN03, things are even worse: it hangs up completely during font download and has to be switched off and on again!) ii) I hope to modify the program shortly to use .PK and/or .GF files in addition to the .PXL files Contact ======= If anyone is experiencing difficulty in installing DVItoLN03, you are welcome to contact the author B Hamilton Kelly Royal Military College of Science Shrivenham SWINDON UK SN6 8LA or via JANET rm001a@uk.ac.cranfield.cdvc (Please mark it for my attention, because that is a ``generic'' address) Good Luck! Brian HK --------------------------------- Date: 30 Jun 1988 12:06:58-WET To: Info-TeX@aston.mail Subject: PK-format files with LN03 and LN03+ on VMS From: alien Hidden away in the Unix TeX archive at Aston is a version of Flavio Rose's DVI2LN3 which works with PK-format files under VAX/VMS. So VMS sites with LN03s or LN03+s can now get rid of all those wasteful PXL files. I'm in the process of making the VMS version interface correctly to DCL. Interested parties should contact me for a copy. **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) --------------------------------- Date: 30-JUN-1988 13:55:50 GMT From: CHARLES@UK.AC.OXFORD.VAX To: info-tex@UK.AC.ASTON Subject: DosTeX: DEBOO without the RSX dependency Can someone provide a copy of DEBOO which does not depend on having RSX emulation on a VMS system? Many thanks, --Charles Curran --------------------------------- Date: Thu, 30 Jun 88 14:57:28 BST From: Roger_Gawley @ UK.AC.DURHAM To: info-tex @ UK.AC.ASTON Subject: Agfa P400 and P3400PS printers Does anyone have or know the whereabouts of a set of Computer Modern fonts at 406dpi for the Agfa P400 laser (well LED) printer? I should say that Durham University do not have such a machine at present: the availabilty of suitable fonts is one factor that we are considering. We are in fact more likely to buy the P3400PS ("baby Agfa") printer. This is much cheaper for a similar specification suggesting that it is a completely different engine which might require different pixel files for best results. Any information on this or any related points would be very welcome. In fact I think that the real dot spacing for both devices is 406.4dpi (=16dot/mm). I will see replies sent to info-tex but should see them sooner if sent direct to Roger_Gawley@uk.ac.durham Roger Gawley Computer Centre University of Durham South Road Durham DH1 3LE 091-374 2874 --------------------------------- Received: from logcam.uucp by kestrel.Ukc.AC.UK with UUCP id aa09572; 30 Jun 88 14:47 BST From: Colin Grant Date: Thu, 30 Jun 88 13:45:15 BST Message-Id: <12330.8806301245@socrates.logcam.co.uk> To: chris@uk.ac.sheffield.aivru Cc: sun@uk.ac.cardiff, info-tex@uk.ac.aston.mail Subject: Centralised UK archive server This is a discussion about reducing the amount of source requests sent to the states. I am cross sending this to the UK TeX group, and the UK Sun users group as I believe that it concerns both communities. For the TeX people who might be wondering, Chris Brown (chairperson of the UK Sun User Group) was considering if we could produce a case for Sun to help with financing a central UK archive server for Sun sources. I believe that this is required for both communities. > From: Piete Brooks > I have long planned to set up a caching server. > When a request for an item that is not held locally arrives, a request is > sent out to the master archive and when that returns it is saved and sent on > to the original requestor any anyone else who has requested a copy in the > meantime. > Slightly greater latency, but real sexy ! Yes this is exactly what is required. There is no point in having complete copies of everything that is on the Rice server especially as much of it might be dross. And if we did keep a copy of everything at Rice, are there any other archive servers that we should keep verbatim copies of? From examining the last eight messages from this distribution list (Ah! I now understand what Piete means by DL) it seems that there are two separate USA bound requests for tooltool currently in progress. This duplication is costing someone real money! Note that Alvey (who, I believe, part fund the UK <-> USA link) have already raised concerns about the volume of traffic that flows across the pond, and have considered tighter controls on the funds available. This last point is from memory of an Alvey newsletter, and may be incorrect - apologies to whoever takes exception if this is the case. We also don't want the unsolicited distribution of source that people believe the rest of the DL will be interested in. The obvious example of this is the recent distribution of touchup - although I must admit that we would have requested it anyway. Due to some problem within the DL our site received four copies of part 4/6 and four copies (so far) of part 5/6 - this is costing us real money, and slogs our mail server! So less of the criticism, and more with the positive comments... I believe that there needs to be some central point within the UK to stop multiple requests going to the states. I agree with Piete that there should be some caching server that performs an automatic states-bound request when something is not within the cache. The original requester should be informed of what is happening. Subsequent requests for the source should be informed of when the states-bound request was sent. When the source returns, it should be distributed to those interested. Questions/points + What happens if the states-bound request fails? Can the server software spot this and take appropriate actions. Should the original requester be 'left in charge' of retrieving the situation? + Should this server be bound to Rice only? For instance where does the TeX related stuff come from? Should this also be included on this server? I suspect that this might weaken the case to Sun for discs/funds though - however the cache-server software should be made available for the TeX-archiving people. + Does the storing of people's names for automatic replies contravene the Data Protection Act? > From: Chris Brown > Personally, I would be looking for some > arrangement whereby the server could also meet the needs of user group > members who do not have email (of which there are many); perhaps > through a tape distribution service. I also agree with this. When you are faced with megabytes of source that has to be transferred to your machine the first thing that comes to mind is the cost of it - some of us aren't lucky enough to be in a situation where we don't have to justify large PSS (or even phone) bills. Of course the trouble with using tape to distribute software is the (human) time it takes to physically handle the tape. Could a "request what you like" service be supported, or would it be better to have regular "here's what we've got at the moment, take what you want and pass it onto ...." distribution (with more than one tape)? Given the probable large volumes of data that will be flying around the various mail links, and the fact that a large majority of mail goes via ukc, I suspect that the cache-server (or even the simple server) should be located somewhere close (in monetary/line time terms) to ukc. Will this be a problem to Sun? I suspect that the large volume of data that will need to be stored will mean that the actual archive will need to be distributed across several machines. However this should be transparent to the casual user of the archiver. The central archiver should either respond with a "actually, will you please contact ..." message, or should pass the request onto the appropriate archiver automatically. This implies that there is some overall control of the location of various sources - probably decided by the people who will have to maintain the archivers. The 'secondary' servers should also have the ability to request source from the states if need be - note that the central archiver is still ensuring that only one request goes states-bound, just that the responsibility for the request is delegated. Having a distributed server will require incoming requests to the central archiver are queued so that the 'central committee' can decide who should be looking after the request. This should not cause too much hassle to the users - especially when they consider the service that is being supplied to them. An alternative to this full automated distributed system would be a system where the central archiver acts as previously described (before this distributed stuff), but where the administrator of the central archiver can farm out part of the archive to another site when the disc space or mail load becomes a nuisance. Would it still only be the central archiver that makes that states-bound requests? Well this has gone on far longer than I thought it would! If you've managed to keep with me until now then thank you for listening (or is it reading?). Any comments? Regards, Colin. +--------------------------------+---------------------------------+ |Colin Grant |Phone: +44 223 66343 | |Logica Cambridge Limited | | |Betjeman House |UUCP : colin@logcam.co.uk | |104 Hills Road | colin@logcam.uucp | |Cambridge CB2 1LQ | ..!mcvax!ukc!logcam!colin | +--------------------------------+---------------------------------+ --------------------------------- !! !! !! Replies/submissions to info-tex@uk.ac.aston please !! distribution changes to info-tex-request@uk.ac.aston please !! !! end of issue