TeXhax Digest Thursday, December 17, 1987 Volume 87 : Issue 102 [SCORE.STANFORD.EDU]TEXHAX102.87 Editor: Malcolm Brown Today's Topics: Immoderate notes 118 dpi font query TeX for the IBM PC RT Knuth's talk on Dec 7. Re: Low resolution fonts Re: Textures & Latex, Amstex, fonts METAFONT KSTFONTS.......TEX TEXT VIA National character sets in TeX combining verbatim and center ---------------------------------------------------------------------- Date: 15-Dec-87 From: Malcolm Subject: Immoderate notes %%% A number of issues ago, I mentioned that the digests from 1986 %%% were about to be removed due to lack of disk space. %%% Thanks to Eric Berg of the Stanford GSB, who uttered some magic %%% incantations, TeXhax now has considerably more disk space at its %%% disposal. This means that the 1986 digests will be kept on-line. %%% Thanks again to Eric for this assistance. %%% %%% Eventually, of course, even this increased disk space will fill up. %%% This raises the question of the importance of archiving past %%% TeXhax digests. Perhaps you'd care to submit opinions regarding %%% this, so we could see whether it is worth arranging. %%% %%% Incidentally, I am maintaining an informal archive of all TeXhax %%% digests on floppy disks. When I revived TeXhax in late 1986, I %%% sorted out all the old issues that were on Score and kept them on %%% floppies. The earliest issues were done by Dave Fuchs at the time %%% TeX82 was first being released. %%% Malcolm ------------------------------ Date: Wed, 9 Dec 87 00:36 GMT From: Peter Flynn 1. BARCODES I was interested to see Dmitri Vulis' findings on bar codes using MetaFont. I know this may sound kinda cooky, but surely there is no need for MF to do this, TeX is quite capable of positioning a set of horizontal or vertical lines using \hrule and \vrule. Why take the hard way? 2. HPLJ2 PCL --> PS We run a HPLJ2 on a PC for TeX, works fine. I don't know much about PDLs, and we don't yet have a PostScript laser printer, but it occurred to me that some- one out there might have routines to translate HP's PCL into Adobe's PS and/or vice versa. Reason being we have some s/w which *only* outputs to PS or to an Epson FX (actually the SCORE music typesetter, TeX's stable companion from Stanford). Would be *real* nice to translate the PS o/p file from that into a HP PCL file so it can be \special-ed into a piece of TeX output. Anyone got any bright ideas? We just can't afford a PostScript machine just yet. 3. BEEBE DRIVER FILES A number of BITNETters have asked me if I can FTP the Beebe files from KIRK.ASTON.AC.UK for them and ship them on. There is a server on EARN which has the files (note from Peter Abbott recently) and EARN ::= BITNET for all intents. Nevertheless, I have the whole DVI208 collection in a PC ARC file which I can ship via VMSDUMP across BITNET to another VAX/VMS site if anyone wants it. Weekends only, to minimise network congestion, it's under 500k. I will be putting the DVI210 files into the same format next week. Mail me if you're interested. 4. FLAVIO ROSE'S (AND OTHER PEOPLES') DVI2LN3 A lot of people have griped about getting DVI2LN3 working (also others have said how easy and good it is). We're just bringing TeX up on a VAX 11/780 here. Can anyone offer installation guidance for the DVI2LN3, as the K&S docs are *very* skimpy on installing it. Also is there a version which takes .PK files, as the multimeg requirements of .PXL did not impress our Systems Manager one little bit! 5. POUND SIGNS Neither Peter Abbott nor Leslie Lamport should be using {\it\$} to get a pound-sterling sign, it's very naughty, unless you are setting in italics anyway. Nor should anyone else, for that matter, and this applies even to sites nearer home: are you listening, Maynooth???!!! There is a perfectly good upright pound sign in cmu10 which should be used when setting normally (use \font\upr=cmu10 \def\pounds{{\upr\$}}). Peter Flynn | Telephone.....................+353 21 276871 x2215 Academic Projects Manager | Facsimile...........................+353 21 277194 Computer Bureau | Telex................................75583 uncc ei University College | BITNET/EARN......................CBTS8001@IRUCCVAX Cork, Ireland | HEANET/JANET.............CBTS8001@IRL.HEA.UCC.VAX1 ---------------------------| InterNet..cbts8001%iruccvax.bitnet@cuny.cunyvm.edu ------------------------------ Date: Wed, 9 Dec 87 10:39:15 GMT From: Peter Ilieve Subject: 118 dpi font query Prompted by various posted bugs in the mf code and the desire for some more magnifications I remade all my fonts. The 300 dpi ones came out looking the same as the old ones from the Unix tape but the 118 dpi ones were very different, looking much lighter. I use the 118 dpi fonts for my Sun and remade them with the Sun mode_def settings from UIUC.mf (blacker:=0 fillin:=0 o_correction:=0.2). Some examples from cmr10.118gf are below. Old: .....X.......... XXXXXXXX........ XXXXXX.XXXX..... .....X.......... ..XX....XX...... ..XX...XX....... ....XXX......... ..XX....XX...... ..XX...X........ ....XXX......... ..XX....XX...... ..XX..X......... ....XXX......... ..XX...XX....... ..XX.X.......... ...X..XX........ ..XXXXXXX....... ..XXXXX......... ...X..XX........ ..XX....XX...... ..XX.XXX........ ...XXXXX........ ..XX....XX...... ..XX..XX........ ...X..XX........ ..XX....XX...... ..XX...XX....... ..X....XX....... ..XX...XXX...... ..XX...XX....... XXXX..XXXXX..... XXXXXXXXX....... XXXXXX.XXXX..... New: .....X.......... XXXXXXXX........ XXXXX..XXXX..... .....X.......... ..X.....XX...... ..X....XX....... ....X.X......... ..X......X...... ..X...XX........ ....X.X......... ..X......X...... ..X..XX......... ....X.X......... ..X....XX....... ..X.XX.......... ...X...X........ ..XXXXXXX....... ..X.XXX......... ...X...X........ ..X.....XX...... ..XX..X......... ...XXXXX........ ..X......X...... ..X....X........ ...X...X........ ..X......X...... ..X....X........ ..X.....X....... ..X.....X....... ..X.....X....... XXXX...XXXX..... XXXXXXXX........ XXXXX..XXXX..... The K in particular is strange, it is mostly thinner but the upper diagonal is thicker than before. So, what were the distributed 118 dpi fonts designed for and what mode_def settings were used to make them? The Sun mode_def settings are the only 118 dpi ones in any files on my Unix tape (from August 86). Peter Ilieve peter@memex.co.uk peter@memex.uucp ------------------------------ Date: 09 Dec 87 14:38:50 AST From: "Steven Osborne - Computer Science UNB" Subject: TeX for the IBM PC RT I am interested in getting in contact with anyone who has got the TeX distribution running and an IBM PC RT with BSD4.x If there is anyone out there with a previewer that would work on the RT I am greatly interested and would appreciate any help I could get. Sincerely Yours Steven Osborne Hardware Systems Specialist School of Computer Science University of New Brunswick ------------------------------ Date: Wed, 09 Dec 87 14:08:10 EDT From: Dimitri Vulis Subject: Knuth's talk on Dec 7. Donald Knuth gave a talk at CUNY GC (where I am a student) on Monday. The talk was extremely exciting and dealt with his new algorithm for rendering a gray scale image on a binary device. The paper will appear in ACM Trans. on Graphics, October issue 'coming out now', so I will not attempt to summarize it here. The results were really impressive. He said that he envisions a convergence of gray scale and line-and-arc technologies. I spoke to him for a few minutes after the talk. It was a kind of religious experience for me. He's a genius. Knuth liked the idea of the fj ligature for Norwegian. He said that upper 128 positions are free and can be used for such additions. He mentioned that Scandinavians also use ligatures for f followed by an umlauted letter, which I was not aware of. I also asked him about TeXXeT: In the TUGBoat paper, Knuth shows the way of making TeX typeset right to left by adding two new DVI opcodes R and L; when the device driver receives L, it stacks everything until it receives R and then outputs it in reverse. I asked him why not have TeX itself do that, because then you can use old device drivers; i.e. the code that outputs the DVI file can stack everything and output it in reverse. Knuth pointed out that there would be a limit on how much data can be thus buffered, but otherwise the same limit would be present in the device driver. One might also stack the data in MEM, rather than allocate a static buffer. Knuth also said that a Russian version of TeX would be a good idea. Unfortunately, AMS CYR fonts (written in old METAFONT) are pretty much unlike 'other' Russian fonts; they also lack Sans-Serif and Cursive (sort of like Italic) which every good Russian typesetter must have. Someone should probably design new Russian fonts from scratch rather than try to convert AMS CYR fonts (as opposed to MSYM and MSXM). ------------------------------ Date: Wed, 9 Dec 87 13:03 PDT From: Don Hosek Subject: Re: Low resolution fonts >Date: Sun, 06 Dec 87 20:15:18 IST >From: "Jacques J. Goldberg" >Subject: Low resolution fonts. >To: Don Hosek > >Sorry I can't help you - but perhaps you can help me: > >I'm running Metafont (1.0 and 1.3 behave the same way on that respect) under >VM to create 120dpi fonts for the fast draft quality DOTPRNT driver for >Epson printers, distributed with Addison-Wesley's MicroTeX. > >Fonts get created correctly at higher magnifications (magstep 3,4) but Metafont >impolitely blows me out at magstep 0,H,1,2 at various places in the CM fonts. > >Errors seem to always occur with y coordinates (after vround for example) >probably due to the strange aspect_ratio. > >Have you ever heard about any such problem ? I append an example. >Thanks / Jacques. > >Note: the job was run in batch mode (VM) this is why the operator's >answers do not show up on the log (&plain, input waits (more devices), >input the_font). * * * [section omitted from note -dh] >(CMSL8.mf (cmbase.mf) (roman.mf (romanu.mf [65] [66] [67] [68] [69] [70] >[71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] >[86] [87] [88] [89] [90]) (romanl.mf [97] [98] [99] [100] [101] [102] [103] >[104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] >[116] [117] [118] [119] [120] [121] [122]) (greeku.mf [0] [1] [2] [3] [4] >[5] [6] [7] [8] [9] [10]) (romand.mf [48] [49] [50] >> 0 ENE 1 NNE 2 3 (ENE ESE SSE) SSW 0 (SSE ESE) >! Strange path (turning number is zero). > > ; >l.88 filldraw z5r--z6l--z6r--z5l---cycle; > % middle tip >? > >******************************* >And this is the device definition (for comparison, I had no problem with >mode = epson at 240dpi) , mode = epslo >******************************* >mode_def epson = % Epson > proofing:=0; % no, we're not making proofs > fontmaking:=1; % yes, we are making a font > tracingtitles:=0; % no, don't show titles in the log > pixels_per_inch:=240; % lowres > blacker:=0; % don't make the pens any blacker > fillin:=0; % and don't compensate for fillin > o_correction:=.2; % but suppress most overshoots > aspect_ratio:=9/10; % 216 dots/inch vertical > enddef; > > >mode_def epslo = % Epson > proofing:=0; % no, we're not making proofs > fontmaking:=1; % yes, we are making a font > tracingtitles:=0; % no, don't show titles in the log > pixels_per_inch:=120; % lowres > blacker:=0; % don't make the pens any blacker > fillin:=0; % and don't compensate for fillin > o_correction:=.2; % but suppress most overshoots > aspect_ratio:=18/10; % 216 dots/inch vertical > enddef; The problem with the CM fonts seems to occur for certain fonts (the italics are another offender) at low resolutions (under 200dpi seems to be the problem resolution). \begin{conjecture} I believe the problem occurs with attempts to describe a very short path at low resolutions. My understanding is that when MF generates fonts, it uses as its working coordinates, pixel coordinates. This runs into problems when several points are very close together. MF may receive what appears to it to be instructions to turn from one point onto itself, thus giving the "strange turning error" message. It is not sufficient to simply set turningcheck:=0; this has two undesirable effects: (1) it still does not compensate with division by zero errors that occur when MF attempts to calculate paths (these are also a result of the low resolution), and (2) It tends to not draw diagonals on V and Y (as described in a previous note I sent to TeXhax) that normally are present (I believe this is a MF or CM bug; I'm waiting for my copy of MF 1.3 to see if the problem still exists with the new version. If so, I will write a letter to Professor Knuth describing the problem (Prof. Knuth, if you're listening now, you may wish to check into this yourself).) The work-around I found for generating the fonts was to run MF with batchmode on. This, however gives bad results for \alpha in cmmi10, N in cmss10 and possibly others (I haven't had tie to check too closely on these) at 78dpi (and possibly other resolutions, I haven't had time to check these either). -dh ------------------------------ Date: Wed, 9 Dec 87 08:42:28 EST From: osupyr!gae@ucbvax.Berkeley.EDU (Gerald Edgar) Subject: Re: Textures & Latex, Amstex, fonts king%entropy.ms@beaver.cs.washington.edu (Jim King) writes: > What do you need to produce fonts that can be >used with TeXtures? Those cute little suitcase files are neater than I wrote for my own purposes a C program that runs under UNIX, and takes a PK file and produces the RMaker source for the corresponding Macintosh font. Is that what you had in mind? I sent it to comp.sources.mac last summer, but apparently it got lost. ------------------------------ Date: Thu, 10 Dec 87 10:28 GMT From: Peter Flynn Subject: METAFONT Can anybody help? I have pcMetaFont just installed and am starting to learn it. But what I need *right now*, immediately, is cmssbx10 scaled \magstep2 and 3 and I just can't see *anything* in the MFbook or the docs with the prog on how to do this. I know it's just blowing up the design size, but I need it real quickly. Any ides? Peter Flynn (CBTS8001@IRUCCVAX.BITNET) ------------------------------ Date: Thu, 10 Dec 87 12:31:50 ZONE From: ASSOUL%FRSAC11.BITNET@WISCVM.WISC.EDU Subject: KSTFONTS.......TEX TEXT VIA Did anyone hear of KSTfonts for TeX, are the Metafont sources for these fonts available? E.Assouline ... Paris ... France ------------------------------ Date: Thu, 10 Dec 87 13:48:33 Greenwich Mean Time From: Subject: National character sets in TeX In TeXhax #99, Per Westerlund asks for comments on the adaptation of TeX to the Swedish language. The same comments apply to many other languages. The following emerged from a number of discussions with other people, namely Frank Mittelbach, Hubert Partl, Reinhard Wonneberger and others. 1. TeX itself TeX is capable of handling fonts with up to 256 characters but some of its parts are limited to 7-bit characters, namely input and hyphenation. It would be relatively easy to create a version of the program that deals with 8-bit characters at every point but that would make TeX input files and hyphenation patterns nonportable. Knuth himself recommends in the TeXbook to create special font families for other languages by moving unwanted characters into places above 127 and using the free slots for the language specific glyphs. That leaves the question how to access the characters. The best way (from TeX's point of view) is to define appropriate ligatures, e.g. use `` "a '' to get a german umlaut (an accented a). This method works for the hyphenation patterns, too. For the characters above 127 ligatures or control sequences may be used. 2. National keyboards The problem is now that typists that normally use a certain national keyboard have great problems in typing those two character sequences. But this can easily be mended by providing a simple filter utility converting files typed in by means of a national keyboard into files TeX can understand. The command invoking the special, say, swedish TeX on your machine would then first call that filter, generating an intermediate file, and then TeX itself which will read the intermediate file. You'll have to set up the filter program so that other files included by means of an \input or \include command are translated, but this can be done easily. 3. Portability considerations This approach also solves the problem of portability since these intermediate files can be used at every TeX installation in the world provided that either a) the other installation has the appropriate fonts available or b) they have a TeX input file that causes TeX to interpret the language specific character sequences as certain TeX commands to get the right characters. That's not as good as the first solution but it works. (That's the interim solution for the german language, see the GERMAN.STY file that Hubert Partl submitted to the LaTeX style collection and his message in TeXhax #99.) In principle it is possible to use the ANSI-standard code-extensions for these special character sequences but this is not portable to all other systems (e.g. IBM with EBCDIC character set). And you cannot send those files via electronic mail; nobody knows what these mailers will do with your escape sequences. 4. Font problems What I said before leads to the conclusion that you have a separate set of fonts for every language. In my opinion this is the right way to do it (it's also the way the TeXbook suugests). You need roughly four megabytes of mass storage for a full set of CMR fonts in all magnifications (in .PK format), therefore only PC implementations might get into trouble. PXL files cannot be used for the new font families because the .PXL format does not support more than 128 characters per font. If you are one of these unfortunate TeX users who are still using .PXL files (I'm one of them, too) you should try to upgrade to a driver that uses .PK or .GF format. This will save you a lot of mass storage so that you can easily hold two or three font families for different languages. (By the way: the .PXL format doesn't even support aspect ratios <> 1, i.e. printing devices with different horizontal and vertical resolution.) Any other suggestions? Somehow we should arrive to a solution for the whole TeX community. Rainer Sch\"opf Inst. f. Physik Univ. Mainz Staudinger Weg 7 D-6500 Mainz West Germany ------------------------------ Date: Thu, 10 Dec 87 10:44:31 EST From: gary%right.mcs@omnigate.clarkson.edu Subject: combining verbatim and center What kind of box is returned by the verbatim environment? I am interested in centering the result of verbatim, and nothing seems to have much effect. \begin{center} \begin{verbatim} Try a few lines \end{verbatim} \end{center} puts the output at the current margin. Is there any hope? ------------------------------ %%% %%% subscriptions, address changes to: texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% submissions to: texhax@score.stanford.edu %%% %%% BITNET redistribution: TEX-L@MARIST.BITNET (list server) %%% %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------