TeXhax Digest Tuesday, August 16, 1988 Volume 88 : Issue 73
Moderator: Malcolm Brown
Today's Topics:
TeXhax Digest V88 #70
Wide Labels and BibTeX
METAFONT answers
\halign and \obeyspaces
gftopk.c
a) LW II NTX modes b) two column LaTeX
Token-by-token processing of macro arguments
Re: TeXhax Digest V88 #70
Question about math in 'Huge' size
"multi-hyphen patch"
Need of a TeX previewer and driver
Help with pk files on vms
Putting a QED box at the end of a Proof
Page-breaks in LaTeX eqnarray environments.
software for multiple change files
TP4 TeX
VMS WEAVE
The best way to do pictures in TeX
compiling C TeX with Gcc version 1.21
----------------------------------------------------------------------
Date: Sat, 6 Aug 88 15:14:25 PDT
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: TeXhax Digest V88 #70
There was a bug in the mode_specials sent out both through TeXhax and
in the Unix TeX distribution U_Wash.mf file. It prevents the use
of smode, because it assumes that mode is always an integer. Fortunately,
the fix is easy:
Just substitute this revised section at the end of the U_Wash.mf file
or whatever mode_def file you use. It includes the Xerox world stuff
as well.
% Macros to add mode information specials to fonts.
def mode_special(suffix $) =
string s,d;
s:=str$; d:=decimal scantokens s;
special s&":="&d&";" enddef;
def font_mode_specials =
p_p_i=pixels_per_inch/mag;
if fontmaking > 0:
begingroup; save d,s,p; save pixels_per_inch;
string p;
pixels_per_inch:=p_p_i;
special jobname;
mode_special(mag);
if string mode: p:=mode;
else: p:=substring(0,length(mode_name[mode])-1) of mode_name[mode]; fi
special "mode:="&p&";";
mode_special(pixels_per_inch);
mode_special(blacker);
mode_special(fillin);
mode_special(o_correction);
endgroup;
fi
enddef;
% Finally, here are macros for Xerox-world font info.
% These can be useful even if you never use a Xerox printer.
% For instance, crudetype uses the |coding_scheme|
% and it is nice to have the font family on record. Some
% of this goes into the TFM, rather than the GF file.
def font_family expr s = % string s names the font family, e.g., "CMR"
headerbyte 49: BCPL_string(s,20);
special "identifier "&s enddef;
def coding_scheme expr s = % string s names the scheme, e.g. "TEX TEXT"
headerbyte 9: BCPL_string(s,40);
special "codingscheme "&s enddef;
def font_face_byte expr x = % integer x gives the family member number,
headerbyte 72: x; % which should be between 0 and 255
special "fontfacebyte"; numspecial x enddef;
def BCPL_string(expr s,n)= % string s becomes an n-byte BCPL string
for l:=if length(s)>=n: n-1 else: length(s) fi: l
for k:=1 upto l: , substring (k-1,k) of s endfor
for k:=l+2 upto n: , 0 endfor endfor enddef;
Xerox_world:=1; % users can say `if known Xerox_world:...fi'
inner end;
def bye=
if fontmaking > 0: font_family font_identifier_;
coding_scheme font_coding_scheme_;
font_face_byte max(0,254-round 2designsize);
font_mode_specials; fi
end
enddef;
outer bye,end;
------------------------------
Date: Sat, 6 Aug 88 19:20 EST
From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)"
Subject: Wide Labels and BibTeX
In a recent TeXhax, I pointed out an apparent problem in BibTeX's algorithm
for choosing the largest label in a bibliography. Oren Patashnik convinced
me that BibTeX was, in fact, correct, given that I was "fooling" it by a
misuse of \etalchar.
After more hacking, I've found a workaround of sorts. What it does is ensure
that \etalchar really does expand to what BibTeX thought it would, at least
withint \thebibliography. The resulting spacing may be too wide, but it
should be pretty close if the spacing WITHOUT the hack was too narrow:
@preamble{"\let\BIBITEM=\bibitem"
# "\def\bibitem{\def\etalchar##1{}\let\bibitem\BIBITEM \bibitem}"
}
In the process of doing this, I did find a limitation in BibTeX (which Oren
tells me will be fixed in the final version): BibTeX tries to keep the lines
in the BBL file short (<79 characters or thereabouts). It can almost always
do this by breaking at a space, which has no effect. But if you use
@preamble's with no spaces, you can get a random break that won't work.
That's why there's a space after \BIBITEM in the second line above - it
gives BibTeX soemthing to grab onto.
BibTeX may also do the wrong thing if comments appear in @preamble text.
Avoid them for now.
-- Jerry
------------------------------
Subject: METAFONT answers
From: adk1%FSU.BITNET@CUNYVM.CUNY.EDU
Date: Sun, 7-AUG-1988 22:23
TeXhax Digest Friday, August 5, 1988 Volume 88 : Issue 70
From: <ADK@vaxino.scri.fsu.edu>
Subject: Metafont question
... I modified the existing local.mf file... and I put this
into my own directory. I then used
mf "\mode=localfont; mag=1; input cmr10"
to create cmr10 at magstep 1... it didn't work. The above
command originally produced a file CMR10.300GF for the ln03
and with the new local.mf it should (I think) have produced a
new file CMR10.somethingelseGF, instead I got CMR10.300GF
again.
What am I doing wrong??? I should be getting a different size
GF file, shouldn't I???
--------
You never told METAFONT to look at your LOCAL.MF file! Try using the command
line
mf "\input local; mode=localfont; mag=1; input cmr10;"
This has the disadvantage that your output files will be called LOCAL.<size>GF,
LOCAL.<size>TFM etc., but will do what you want. The "proper" way to solve
your problem is to do as the METAFONT book says: run INIMF, input PLAIN, then
input LOCAL, and then use the DUMP command to produce a new base file. This
file can then be used by typing "&plain" at METAFONT's "**" prompt, or
presumably by using the command line
mf "&plain; mode=localfont; mag=1; input cmr10;"
To avoid having to load the PLAIN.BAS file everytime some implementations
allow you to create a version of METAFONT with your new base file preloaded.
The details of how to do this depend on whose VAX/VMS port of METAFONT you are
using, as do the details of command line syntax (that is why the METAFONT book
always tells you what to type at it's "**" or "*" prompts even though we all
input the file name on the command line in reality).
------------------------------
Date: 7 Aug 88 23:58 -0500
From: Michael Doob <mdoob%ccu.umanitoba.ca@RELAY.CS.NET>
Subject: \halign and \obeyspaces
In TeXhax v88/67 Gavin Burnage raises the following problem:
< Date: Wed, 20 Jul 88 13:42 N
< From: <GAVIN%HNYMPI52.BITNET@Forsythe.Stanford.EDU>
< Subject: Problems combining \tt, \obeyspaces, and \halign
<
< I'm trying to typeset `tables' which represent the menu screens in a user
< interface display. Because the typewriter type font characters have
< identical widths, I figured the easiest way to do this (experienced but
< sensitive Wizards please brace yourselves) would be with the
< \obeyspaces command: I can copy the menu display straight into the file
< as it appears on screen.
<
< The macro below almost works.
<
< However, on the left hand side of the table, between the vertical bar and
< the text, mysterious spaces are inserted. I don't know why they appear,
< so naturally, I don't know how to get rid of them. Can anyone explain and
< resolve this problem, or point me to the (thus far elusive) appropriate
< TeXbook reference?
<
< $${\vbox{
< \tt
< \obeyspaces
< \frenchspacing
< \offinterlineskip
< \hrule height 1.5pt
< \halign {&\vrule width1.5pt#&
< \strut#\cr
< height10pt&\omit&\cr
< &{ MAIN MENU }&\cr
< &{ }&\cr
< &{ Lexicon: Application: Environment: }&\cr
< &{ LIST SHOW SQL*PLUS }&\cr
< &{ CREATE TABLE VMS }&\cr
< &{ MODIFY UNLOAD }&\cr
< &{ DROP LOAD INSTALL }&\cr
< height10pt&\omit&\cr
< \noalign{\hrule height 1.5pt}
< }
< }
< }
< $$
<
<
< Gavin Burnage
< CELEX -- Centre for Lexical Information Reply:
< University of Nijmegen GAVIN@HNYMPI52.BITNET
< Wundtlaan 1
< 6525 XD NIJMEGEN
< The Netherlands
<
< ------------------------------
<
The source of the problem is the interaction of \halign and
\obeyspaces. The spaces are caused by the template, which obeys the
unwanted spaces before the \strut. The problem can be avoided by
placing the template on one line, or by putting the & directly before
the \strut.
Michael
------------------------------
Date: Sun, 7 Aug 88 22:44:23 PDT
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: gftopk.c
The programs in the Unix TeX subdirectory ./tex82/METAFONT/CMFware,
(formerly ./mf84/CMFware) are of particular importance while web2c
change files for the MFware webs are being prepared. It is therefore
important to note that Tom Rokicki has corrected a bug in gftopk.c
which has shown up in processing fonts with zero-length rasters, such
as the latex invisible fonts. The repair is in a single line. Here
it is, with lots of context.
*** /u4/mackay/gftopk.c Sat Aug 6 14:14:09 1988
--- /u4/mackay/Gftopk.c Sat Aug 6 14:18:05 1988
***************
*** 296,306 ****
putptr = 0 ;
rowptr = 2 ;
repeatflag = 0 ;
state = true ;
buff = 0 ;
! while ( row [ rowptr ] == ( - 99998 ) )
incr ( rowptr ) ;
while ( row [ rowptr ] != ( - 99998 ) )
{ i = rowptr ;
if ( ( row [ i ] != ( - 99999 ) ) && ( ( row [ i ] != extra ) || (
row [ i + 1 ] != width ) ) )
--- 296,306 ----
putptr = 0 ;
rowptr = 2 ;
repeatflag = 0 ;
state = true ;
buff = 0 ;
! while ( row [ rowptr ] == ( - 99999 ) )
incr ( rowptr ) ;
while ( row [ rowptr ] != ( - 99998 ) )
{ i = rowptr ;
if ( ( row [ i ] != ( - 99999 ) ) && ( ( row [ i ] != extra ) || (
row [ i + 1 ] != width ) ) )
-------------------------------cut here----------------------------------
Email: mackay@june.cs.washington.edu Pierre A. MacKay
Smail: Northwest Computing Support Group TUG Site Coordinator for
Lewis Hall, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
------------------------------
Date: Fri, 05 Aug 88 11:42:05 BST
From: CMI011%IBM.SOUTHAMPTON.AC.UK@Forsythe.Stanford.EDU
Subject: a) LW II NTX modes b) two column LaTeX
A) Can anyone supply me, or point me at, suitable MF definitions
for a Canon SX laser engine, such as wot is in the LaserWriter II NTX?
DOes anyone have any feelings on whether I should rebuilt all the fonts
I have been using on an old LaserWriter?
B) I have been trying to set a book in two column mode with LaTeX
(dont ask why, I think I just decided not to after all). Anyway, I thought
in my innocence that a figure or table which spanned two columns
(asked for with figure* or table*) would coexist with two column
text. It doesn't - the smallest table occupies a page by itself.
Is this a feature or a bug? (and yes I have spent some hours in
the book looking for an answer!) Either way, can anyone suggest a
workaround? It really is rather silly to have really quite short
(but wide) tables occupying a whole lonely page. All in all, that
twocolumn mode is what we used to call a 'bummer'...
(sorry Dr L, but the rest is wunnerful)
sebastian rahtz, computer science, southampton
------------------------------
Date: Mon, 8 Aug 88 08:57 PST
From: "Jim Seidman" <JSEIDMAN%HMCVAX.BITNET@Forsythe.Stanford.EDU>
Subject: Token-by-token processing of macro arguments
I've been trying (without much success) to generate a TeX macro which
will automatically typeset chemical formulas for me. For example, I could
just say "\chemical{(CH3)3(CH2)12MgBr}" and all the digits would be
automatically subscripted. At first I thought I could do something like
this:
\def\chemical#1{\chemchar{\aftergroup#1}}
\def\chemchar#1#2{\appropriatelytypeset#2\chemical#1}
\def\appropriatelytypeset#1{%Code to figure out if the character is a number,
%and typeset it accordingly.
Not only is this probably a terribly inefficient way of doing this,
but it doesn't work either, nor does any combination of \expandafter's,
\edef's, etc. seem to help. I know that if I want to do something like
place a "\\" between each two characters I can just do list processing as
described in the TeXbook, but I'm hoping there's a more elegant solution
to getting a character at a time. Any suggestions?
------------------------------
Date: Mon, 08 Aug 88 09:14:37 PLT
From: Dean Guenther <GUENTHER%WSUVM1.BITNET@Forsythe.Stanford.EDU>
Subject: Re: TeXhax Digest V88 #70
> From: "Jim Seidman, Reanimator-in-training"
> Subject: Question concerning Hershey fonts
> (Yes, I realize part 1 was actually 2 questions... so sue me.) Does
> anybody know of a program to covert Hersey fonts into METAFONT input? If
> not, does anybody know of a program to make TFM files for Hersey fonts,
> or even an algorithm to do so?
Scott Guthery, 512-258-0785 has the Hershey fonts with TFMs for a nominal
fee. $20-$30 I think.
Dean Guenther
TeX IBM VM/CMS Site Coordinator
Washington State University
Pullman, Wa.
99164-1220
phone: 509-335-0411
BITnet: GUENTHER@WSUVM1
------------------------------
Date: Mon, 8 Aug 88 09:22:26 PDT
From: chase#lila%c.mfenet@NMFECC.ARPA
Subject: Question about math in 'Huge' size
I see the sizes are set in lfonts.tex. Why is it for 25 pt that
When math is done in size "Huge", the integral limits are out of
proportion. I believe poor choices are made in lfonts.tex. Shouldn't
they be changed?
------------------------------
Date: Mon, 8 Aug 88 12:07:59 PDT
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: "multi-hyphen patch"
The multi-hyphen patch sent over by Antti Louko came with some character
damage cause by trans-Atlantic travel, but I think I have it in shape.
Although it passes trip, and can masquerade as TeX, it is not fully
interchangeable with TeX (input files for this version would not run through
TeX) and a new name is required. Ftex or Finntex would in some ways be
appropriate, but what Antti Louko has done is more general than just to
provide a Finnish TeX. How about mhtex (mhinitex mhvirtex mhtex.pool)?
Scarcely pronounceable even in Irish, but fairly informative. I
will add to the received patch the lines that will rename the program
and the pool file.
There was one minor adjustment found in the multihyph patch
that really belongs in the base ctex.ch file.
X_make_name_string ought to be in pascal verticals---|X_make_name_string|
I haven't really tested mhtex yet. If anyone has a multilingual problem
that could use it, pick it up by ftp from our pub directory. As soon as
I am sure that all obvious bugs are gone, I will send the corrected file
back for the MULTIHYPH.TXH file on SCORE.
Email: mackay@june.cs.washington.edu Pierre A. MacKay
Smail: Northwest Computing Support Group TUG Site Coordinator for
Lewis Hall, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
------------------------------
Date: Tue, 9 Aug 88 14:07 N
From: <SXOINAS%GRCRVAX1.BITNET@Forsythe.Stanford.EDU>
Subject: Need of a TeX previewer and driver
Hi from Crete.
I am in a need of TeX previewer for Vax/Vms that uses gf font files.
(for Vt125 Regis,Vt240's Tektronic modes mainly)
Does anyone out there know something about it?
Thanks for your time.
I am also in a need of TeX driver for a HP7475 pen plotter.
Also I search for a TeX driver for an LA100 or Epson printer.
Thanks for your time and help.
p.s.I am speaking for Vax/Vms.
------------------------------
Date: 9 Aug 88 11:07 -0600
From: Jim Walker <walkerj%wnre.aecl.cdn%ean.ubc.ca@RELAY.CS.NET>
Subject: Help with pk files on vms
Can somebody PLEASE help me obtain/generate pk font files. I would like to
use Ed Bell's latest version of dvi2ln3, which means that I have to obtain
or generate the pk format files. I have the ams TeX distribution tape, so I
have the gf format files. I think I tangled GFTOPK successfully (no .ch
file), but GFTOPK.PAS file wouldn't compile because of undeclared
identifiers.
Can anybody help me please; i.e. tell me what I'm doing wrong, provide me
with GFTOPK.PAS, give me a .com file to generate all the pk files,
anything!
------------------------------
From: BICKIS%SASK.USask.CA@Forsythe.Stanford.EDU
Date: Tue, 9 Aug 88 16:38 CST
Subject: Putting a QED box at the end of a Proof
Joachim Schrod's solution (11 June) to putting a QED box at the end of
a proof is very comprehensive, but it may fail in one situation: If
the proof ends with a displayed equation. In this case it may happen
that the proof ends at the bottom of a page, and the QED symbol
appears at the top of the next page. Suppressing a pagebreak doesn't
work as part of the \QED macro, since TeX considers a pagebreak
penalty to be the * minimum * of all penalties at that point.
Moreover, an \unskip will not remove glue in the main vertical list.
A way around this is to explicitly set \postdisplaypenalty=10000
before the displayed equation that ends the proof. However, this
cannot be done inside the \QED macro itself, since by the time it is
invoked, the current value of \postdisplaypenalty has already been
placed in the vbox.
This solution appears to work acceptably, except that in some cases it
would look nicer if the QED box appeared on the same line as the
displayed equation. This can be achieved by preceding the \QED macro
with a negative \vspkip of the appropriate dimension. In plain TeX,
one could also pretend that the the QED box is an equation number,
using it as the argument of \eqno. This latter tactic will not work
in LaTeX however. I see of no way that such tactics can be automated
as part of a \QED macro itself.
Mik Bickis
Dept. of Mathematics
University of Saskatchewan
BICKIS@SASK.NETNORTH
------------------------------
From: BICKIS%SASK.USask.CA@Forsythe.Stanford.EDU
Date: Tue, 9 Aug 88 16:56 CST
Subject: Page-breaks in LaTeX eqnarray environments.
I notice that inside an eqnarray environment LaTeX ignores any explicit
commands about pagebreaks, either in its own dialect (\pagebreak or
\nopagebreak) or in terms of TeX \penalty's. Does anyone know if this
is a "known bug" or a "design feature"? Although LaTex will break long
eqnarray's across pages, it does not always put the break in the best
place semantically. I have not been able to figure out how LaTeX decides
on such breaks, so I am not able to override its choice. Any suggestions
would be appreciated.
Mik Bickis
Dept. of Mathematics
University of Saskatchewan
BICKIS@SASK.NETNORTH
------------------------------
Date: Tue, 9 Aug 88 15:40:55 PDT
From: Jeff Copeland <jeff@ism780.isc.com>
Subject: software for multiple change files
Where can I obtain a copy of one of the change file merge programs that
have been discussed in TUGboat in the past year? (KNIT and TWIST as
described by Appelt and Horn in vol 7 #1; TIE, discussed by Guntermann and
R\"ulling in vol 7 #3; or WEBMERGE as described by Sewell in vol 8, #2.)
Unfortunately, I am unable to FTP. However, if one of these is on the
current Unix distribution, we are about due for an update anyway, and will
get it then.
Jeffrey Copeland
...!uunet!ism780c!jeff
------------------------------
Date: Wed, 10 Aug 88 17:24:31 GMT
From: WSULIVAN%IRLEARN.BITNET@Forsythe.Stanford.EDU
Subject: TP4 TeX
I am currently working on a Turbo Pascal 4.0 version of TeX for
IBM PC's and compatibles, which I shall make freely available when it is
in reasonable shape. At the moment a rather strict implementation is running
and giving what I believe to be pretty good trip.log and trip.typ. A fair
bit of work involving IO and checking remains, as well as optimization.
Is there anyone interested in helping? Please do not contact me unless you
are seriously interested in helping and have a fair knowledge of WEB, TeX
and TP4.
The main problem for a practical version is memory limitation. I should
like to include the following modifications which would improve utilization
of the bare 640K that the designers decided upon. I should appreciate
advice on whether there are technical objections to any of these, and
whether the inclusion of any would make the program no longer TeX.
1. Is dynamic determination of mem_top and mem_max O.K.?
2. It would be convenient to store the information now in the array of
font arrays in specialized records in font_info immediately before
the TFM data. An array of pointers would indicate the location of the
font records and data.
3. For the auxiliary trie arrays used when iniTeX computes new patterns
I should like to use space in the mem array between lo_mem_max and
hi_mem_min. I have a hunch that the mem array is not needed while
new patterns are being computed, but could new nodes be generated at
this time?
4. I should like to use nodes from mem as control-block-buffers for the
16 read and 16 write files. For many applications the definition of these
files as global variables results in wasted space. Is there anything
wrong with using a node size of 65 for the cb-buffer?
5. For virTex (not iniTeX) it would be convenient to be able to use mem
to store new font data when the font_info array is full. Here the node
size would be about 350. One could select the size of font_info so that
a mem_max of about 64k would be possible for a 640K PC with no
resident utilities. For programs with lots of fonts, space for fonts
could be taken from mem. One would include a few extra words in the
node in case new font parameters were to be defined.
I should be grateful for comments on these points. Wayne Sullivan
------------------------------
Date: Wed, 10 Aug 88 19:45:45 BST
From: David Barfoot <DTB10%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: VMS WEAVE
There is a bug in the VMS changes to WEAVE 2.8 which causes mishandling
of the `::' type cast operator. A glance at module 27 of the VMS TeX
changes reveals anomalous gaps between the colons, and, more seriously,
accumulating anomalous indentations (which become considerable in so
long a module).
The following additions to WEAVE.CH appear to solve the problem (the
numbers after @x are module numbers):
-----------------------------------------------------------------------
@x [15]
@d carriage_return=@'15 {ASCII code used at end of line}
@y
@d carriage_return=@'15 {ASCII code used at end of line}
@d type_cast=@'27 {equivalent to `::'}
@z
@x [97]
":": if buffer[loc]="=" then compress(left_arrow);
@y
":": if buffer[loc]="=" then compress(left_arrow)
else if buffer[loc]=":" then compress(type_cast);
@z
@x [186]
":": sc1(":")(colon);
@y
":": sc1(":")(colon);
type_cast: sc2(":")(":")(math);
@z
I can mail the complete change file to anyone who wishes it.
| David Barfoot | Phone: 0223 334709 |
| University of Cambridge | Telex: via 81240 CAMSPL G |
| Computer Laboratory | Fax: via 0223 334748 |
| New Museums Site | |
| Pembroke St | BITNET: DTB10%PHX.CAM.AC.UK |
| Cambridge CB2 3QG | ARPANET: DTB10%PHX.CAM.AC.UK@CUNYVM.CUNY.EDU |
| United Kingdom | |
------------------------------
Date: Thu, 11 Aug 88 10:56:14 CDT
From: William LeFebvre <phil@rice.edu>
Subject: The best way to do pictures in TeX
I was just talking to one of my fellow grad students, and came up with
what I think would be the best way to do graphics/pictures in TeX.
This solution would require no \special support by the DVI translator,
and it would even be previewable with a conventional previewer. And
unlike PicTeX, it probably wouldn't require a gargantuan sized TeX
image. I wanted to bounce this off of the TeX community to see what
people think....
The solution? Use MetaFont, of course. Draw your graph, flowchart,
circles, arrows, etc., in MetaFont. I have actually done something
along these lines already: let MF produce it's largest sized gf file
(2602 dpi) and convert that bitmap into an imPress bitmap (I had to
write a program to do this step), then print it. You get a huge blowup
of the bitmap (2602/300) but it looks great. Unfortunately, that still
requires some \special to include a "native bitmap".
So here's an even better solution: have MF produce an entire font for
the picture by tiling it into small chunks. Then to print it in a TeX
file, one only needs to switch to that font and print the characters in
their appropriate places. Poof! No \special support needed, because
it's all done in fonts. This still requires some fancy footwork,
because there is an upper limit on the size of a character that MF can
produce. I was thinking that you could set MF's working resolution
very high (like, say 2600 dpi) to get a large work area, and then use
the actual resolution of the device only when tiling. CAre would have
to be taken to make sure that the image was still portable to any
resolution device (this would introduce some more problems if the
device was a very high resolution).
But there are some great advantages: the document would be
reproducible on any machine running both TeX and MF and on (most) any
printer. Metafont is as maleable as TeX, which means that one could
emulate one's favorite picture drawing environment (such as "pic") on
top of it. That way, your metafont file would look more like pic than
metafont, but for graphics drawing it would be all that you need.
Only three problems need to be solved:
1) make metafont tile an image, producing many characters for
one image
2) positioning text correctly in the image (I haev some ideas
for this, too)
3) deal with widely differing printer resolutions gracefully.
What'cha think? I wish I had the time to do it right now!
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Thu, 11 Aug 88 17:56:18 BST
From: CMI011%IBM.SOUTHAMPTON.AC.UK@Forsythe.Stanford.EDU
Has anyone succeeded in compiling TeX with Gnu CC? I just tried,
out of curiosity, and tho it compiles I get a crash on reading
in the 'hyphen.tex', apparently because Gnu C can't allocate
the memory for the string pool. I haven't pursued it because
I cam not competent to do so, but does anyone have any thoughts
on the matter?
My web2c is 2.17, my Gnu is 1.21 (I think) and I'm on a Sun
sebastian rahtz
computer science, southampton
------------------------------
Date: Thu, 11 Aug 88 11:22:22 -0700
From: Tim Morgan <morgan@beanie.ICS.UCI.EDU>
Subject: compiling C TeX with Gcc version 1.21
I was first able to compile C TeX with Gcc version 1.21 by
defining schar to be "int" in site.h. With gcc 1.24, I was
able to compile the gargantuan version of C TeX without
making this change (i.e., schar was typed "signed char"),
and it passed the trip test even when compiled with optimization
turned on.
The current distribution includes support for TeX, all the TeXware
programs, Metafont, and BibTeX 0.99c. A version of gftype in
C is provided for the trap test. There are people actively
working on the MFware programs.
Tim Morgan
UC Irvine ICS Dept.
------------------------------
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET:
%%% SUBSCRIBE TEX-L <your name> % 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]<TEX.TEXHAX>TEXHAXnn.yy
%%% nn = issue number
%%% yy = last two digits of current year
%%%\bye
%%%
------------------------------
End of TeXhax Digest
**************************
-------