TeXhax Digest Friday, May 1, 1987 Volume 87 : Issue 32 TEXHAX32.87 Editor: Malcolm Brown Today's Topics: TeX v. Mac rejoinder TeX to PostScript BIG \matrix: HELP! WYSIWYG TeX, TeX environments, Incremental TeX TeX versions of UNIX man pages manfnt font align Splitting tables metafont & fonts for LN03 ---------------------------------------------------------------------- Date: Thu, 23 Apr 87 17:41:43 n To: TEXHAX@SCORE.STANFORD.EDU From: Subject: TeX v. Mac rejoinder In his reply to my doubts on TeX's efficacy in the face of DTP products for the ubiquitous Mac, Glenn Vandenburg make some valid points on TeX's strong points - particularly its promotion of "logical design". However, I feel that this approach fails to deal with the way TeX appears to be used by real people, in the real world. Judging from the questions and answers on TeXHax, it seems fairly certain that most TeX users are not full-time computer typsetters, but instead tend to be graduate students writing theses, postdocs drafting resumes, or researchers writing papers/ books. Under such circumstances, I suspect that a fair number of these users (myslef included) often work on documents which are not what I would call "continuous text" - that is, they contain frequent display material, font style and size changes, subsections, indentation etc.. Whilst TeX is fine at handling the `texnical' aspects of setting such documents, I'm afraid that I don't believe that it makes the design of such things practical. Some years back, the most common way to approach such a task would have been the literal application of scissors and glue, now incarcerated in cut-and-paste operations of numerous editors. The ability to easily and visually manipulate sections of a discontinous text document for positioning, font etc., is to me the essence of easy desgin FOR THOSE NOT DOING SUCH THINGS CONTINUOUSLY! I grant that for non-stop TeXHaX's, typesetters, graphic artists, such notions come intuitively, and then, perhaps, logical design is of great consequence. Sadly however, the majority of us are not in a position to design documents in a logical fashion a priori. Oh sure, the breaking of books into chapters and paragraphs comes easy, but I'm sure Glenn see's there must be more to good typography than such low level "logical design". I would contend that TeX, for many users, does nearly the opposite of what Glenn claims - it tends to make them treat the whole document as one thing, rather than sections linked by a logical structure. I'm not sure that current WYSIWYG systems avoid this, but I do feel that a good WYSIWYG system could... As for "what you see is all you've got" - well, I feel that this trite remark, whatever its source reveals a failure to see the potential in menu-driven WYSIWYG systems. A private reply to my posting suggests an example - suppose I define a TeX macro \quote to handle block quotes in a thesis. This, as all TeXHaX-ers know, is very useful because if my thesis committee decides to change its rules for block quotation style then I just change the \def of \quote, without having to isolate every instance of its use. However, there seems to me no in-principle reason why such a macro can't appear in a WYSIWYG menu, and still be subject to change at the drop of a thesis advisor's hat... On a more general level, perhaps Leslie Lamport would like to consider the applicability of this phrase to, say, CricketDraw for the Mac (I think thats its name!) - a full WYSIWYG `painting' system, with access to the system-written/user-amendable PostScript source code in a parallel window..... It's such a system that I feel hold out hope for TeX - VorTeX where are you ? Meanwhile, on that friendly note of Glenn's - the solution for using other fonts in Math Mode was given by the effervescent Ms.Beeton in TeXHaX perhaps three or four issues ago: if you want more info mail me on the net and I'll send it right away. The "other fonts" in this case consist of PostScript fonts like Times-Roman, Helvetica etc., which avoid giving a document that well know TeX-ified appearance in computer journals, a syndrome also known as "I was printed by a laser but in a font designed in the 18th (or was it 19th) century". Lets see Hermann Zapf giving us his beautiful fonts to use - no sarcasm here - and really get into "fine typography". Paul. ------------------------------ Date: Thu, 23 Apr 87 13:59 EDT From: "SDRRTR::PSI%HDSRTR::HDSRTR::MRGATE::\"MRGATE::PSI%SCRVX2::SIMON\"%slb-test.csnet"@RELAY.CS.NET Subject: TeX to PostScript In the April 1987 TUGboat it was suggested that TeX should produce PostScript rather than DVI output. This seems to me to be a mistake. There will continue to be plenty of non-PostScript devices in the marketplace for the foreseeable future and some means must be found to drive them. If TeX produces PostScript, then for each such device a PostScript interpreter will need to be written to convert PostScript into a form understood by the device. But a series of PostScript interpreters is no worse than a series of DVI interpreters, right? WRONG! A DVI file is a list of very simple instructions such as move right n units, move down n units, switch to font f, typeset character x, and so on. It was deliberately designed to be easily read and understood by computers. PostScript on the other hand is a programming language of considerable power and complexity. Implementing PostScript would be more like implementing TeX itself. Simon Barnes Cambridge, U.K. ------------------------------ Date: Thu, 23 Apr 87 13:38:46 PST From: darrell@sdcsvax.ucsd.edu (Darrell Long) To: texhax@score.stanford.edu Subject: BIG \matrix: HELP! I'm typesetting a large matrix (11x11) and it doesn't want to fit. The elements of the matrix are simple $2\lambda+\mu$. When I typeset a matrix with more compilcated things it reduced the point-size auto-magically to fit within the margins. Is there any way I can force this to happen without messing with the fonts? Thanks, DL Darrell Long Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp Operating Systems submissions to: mod-os@sdcsvax.uucp ------------------------------ Date: Sat, 25 Apr 87 21:38:22 PDT From: Jonathan_Thornburg%UBC.MAILNET@MIT-MULTICS.ARPA To: texhax@Score.Stanford.edu Subject: WYSIWYG TeX, TeX environments, Incremental TeX I have 2 points to add to Glenn Vanderburg's reply (v87 #30) to Paul Davis' question (#29) about "WYSIWYG TeX". First off, one of TeX's big advantages is that it can run quite well in an environment far less rich than (say) a Mac. I'm thinking here of something like (say) a 24 x 80 dumb terminal attached (possibly via a slow line) to a (possibly overloaded) mainframe. Many of us don't have Mac's and won't for years to come, but TeX is here today. That said, my second point is that much richer TeX environments are possible. I'm thinking (dreaming) of an "incremental TeX" ("ITeX" for short). Let me explain: present day TeX compiles a program (your typesetting instructions) into a DVI file, which is then either assembled into (say) laser printer codes, or interpreted by a screen previewer. ITeX would be an incremental compiler, taking as input a description of changes to your TeX file (being edited in window #1), and producing as output a description of the resulting changes to the current page. This output would then be interpreted (on the fly, while you're still in the editor in window #1) by an incremental previewer to update a page image on display in window #2. (There is of course no reason why your TeX input file couldn't be in LaTeX, AMS-TeX, or <<>>.) Presumably ITeX's input would be generated (semi-?) automatically by the smart programmable editor running in window #1. ITeX itself and the incremental previewer would each be separate processes, with data sent from editor --> ITeX --> previewer by pipeline. The question of just what languages these data streams should be in, I'll leave as an interesting problem for the (future) designers/implementers of ITeX. The big problem in designing/implementing ITeX is that TeX semantics aren't really set up for incremental processing -- changing a single (macro) definition can produce major changes in the output. However, this doesn't happen very often. Moreover, the same is true of (say) both Pascal and C, yet there exist incremental "update-on-the-fly" programming environments (eg Tektronix's "Magpie" and "Integral C" resp) for both of the latter, running on present day workstations. Note that "Integral C" fully supports C's (crude) macro processor, complete with textual-replacement macros of the TeX variety. (Awakening from the dream) Can this all be shoehorned into a Mac? I doubt it, but perhaps a Mac II, Sun, Apollo, Vaxstation, ... - Jonathan Thornburg userbkis@ubcmtsg.bitnet thornburg%ubc@um.cc.umich.edu ------------------------------ Date: Mon, 27 Apr 87 08:51:59 EST From: "S Bechtolsheim" To: texhax@score.stanford.edu An answer to Darrell Long's question (darrell%beowulf@cdcsvax.ucsd.edu, April 21, 1987) % \crline: generate a centered line (#1) followed by a right justified % line (#2), where the end of the right justified line lines up with the end % of the centered line. % #1: centered line % #2: right justified line \def\crline #1#2{ \setbox 0 = \hbox{#1} % so we can get the length % of the first line \dimen0 = \hsize \advance\dimen0 by -\wd0 % distance: end of centered line to margin \divide\dimen0 by 2 \centerline{#1} \rightline{#2\hskip\dimen0} } \crline{This is a centered line, like a quote or so}% {The quote's author} \bye ------------------------------ Date: Mon, 27 Apr 87 08:31:15 EST From: "S Bechtolsheim" To: texhax@score.stanford.edu Subject: \font and grouping One can not reclaim memory by including \font inside curly braces, in other words {\font\xx = cm... \xx Text} will not free the space occupied by the tfm file of cm... Is there anything else, which does not follow grouping? I am not interested in solving the above problem. I just would like to know, whether there are other things, which do not "obey" grouping. Stephan Bechtolsheim i5f@l.cc.purdue.edu ------------------------------ Date: Mon, 27 Apr 87 08:34:09 EST From: "S Bechtolsheim" To: texhax@score.stanford.edu Subject: Variable number of arguments In response to a message by AGTLEJS%CALSTATE.BITNET@wiscvm.wisc.edu (April 21, 1987) Here is one solution to having a macro with a variable number of arguments. % Count arguments for \varargs \newcount\varargscount % \varargs: this macro can be called with a variable number of % arguments, which are all echoed. Each argument must be enclosed % in {}, and the last argument must be followed by \nomoreargs % Example calls: % \varargs{Life}{is}{fun}\nomoreargs % \varargs\nomoreargs \def\varargs {% \varargscount = 0 \varargsa } % \varargsa: parses the arguments: use \futurelet to look ahead. \def\varargsa{% \futurelet\vartoken \varargsmore } % \varargsmore: this macro calls either \varargsdone, because % all arguments have been exhausted, or it calls \varargsdo % to continue reading arguments. \def\varargsmore{% \ifx\vartoken\nomoreargs \let\next = \varargsdone \else \let\next = \varargsdo \fi \next } % \varargsdone: done with reading arguments % #1: \nomoreargs: just throw it away \def\varargsdone #1{% \message{varargs: done} } % \varargsdo: absorb an argument, and print it out. % #1: next argument \def\varargsdo #1{% \advance\varargscount by 1 \message{Argument \the\varargscount: "#1"}% % Recursive call: continue to parse arguments \varargsa } % Sample applications \varargs{Life}{is}{fun}\nomoreargs \varargs\nomoreargs \bye ------------------------------ Date: Mon, 27 Apr 87 13:25:17 CDT From: David Chase Subject: TeX versions of UNIX man pages To: TeXhax@score.stanford.edu It's REAL sad to see manual pages for TeX tools written in troff. I know that there is a dvi-to-tty converter, so we can scroll them on a page, but is there a troff/man-to-TeX converter so that a true fanatic could convert all that troff junk to TeX and throw troff away? (not that we could ever do that here, but it's fun to think about sometimes) David ------------------------------ Date: Sun, 26 Apr 87 00:45:11 GMT From: CMI011%UK.AC.SOTON.IBM@ac.uk To: TEXHAX@score.stanford.edu Thinking about work for the next 6 months, it struck me that it would be nice to implement some of the suggestions made about extending BibTeX by changing it so that it acted as a front-end to a relational SQL database. BibTeX would then merely issue an SQL call to get its data (passing over the keyword), and the putting together of a suitable set of data would be the database's job. This would enable one to put together a much more rigidly controlled system which could be used for other purposes as well (such as generating Unix `refer' databases!). Does anyone have any experience of this, and/or suggestions? sebastian rahtz cmi011@uk.ac.soton.ibm ------------------------------ Date: Mon, 27 Apr 87 16:39:09 CDT From: dean@dream.wisc.edu (Dean Luick) To: TeXhax@score.stanford.edu Subject: manfnt font We don't seem to have the manfnt font here. Is it available anywere? dean Dean Luick University of Wisconsin - Madison Computer Systems Lab uucp: ...!{allegra,harvard,ihnp4,seismo,topaz}!uwvax!dream!dean arpa: dean@dream.wisc.edu ------------------------------ Date: 27-APR-1987 16:48:50 From: ABBOTTP%UK.AC.ASTON.MAIL%UK.AC.RL.GB@ac.uk To: TEXHAX@score.stanford.edu Aston University - Electronic Mail Date: 27-Apr-1987 16:47 GMT From: Peter Abbott ABBOTTP@UK.AC.ASTON.MAIL Dept: Computing Service Tel No: 021 359 5492 -direct TO: Remote Addressee ( _POST TEXHAX%SCORE.STANFORD.EDU@RL.E Subject: Loss of characters when using newcommand Please can anyone supply a remedy for the following \bf [Exit Screen] to prints correctly \newcommand \exs \bf [Exit Screen] \exs to prints the bold but the t disappears. It has been tried on VAX VMS and IBM PC systems and with other letters in place of the `t'. Inserting a space between the ` ' has no effect. Peter ------------------------------ From: VELTHUIS%HGRRUG5.BITNET@forsythe.stanford.edu Date: Tue, 28 Apr 87 06:37:19 PDT To: texhax@score.stanford.edu Subject: align For a TeX-novice like me (less than 3 months) it feels hubristic to remark on the inner parts of TeX, but there seems to be a possibility that does not conform to the intentions of the designer: it is allowed to end a column in an alignment by producing a tab_mark from a macro at the end of the u_template (details below). This trick can be quite useful (example below), so perhaps this feature was put in (or left in) on purpose. I have the following questions: - is this going to stay in TeX (: can one write macro packages using this trick) ? - if not, is there an (easy) alternative? Probable explanation. \halign (in TeX, VAX/VMS Version 2.0.0) offers the unexpected possibility of ending a column by producing a tab_mark from a macro at the end of the u-part of the template. I am certainly not very familiar with TeX, but it seems that the following gives an explanation. If the u-part ends with a macro call, the procedure macro_call (<389> in "TeX : The Program") is invoked. This procedure contains module <390>, which feeds the macro body and its parameters to the scanner, but which first cleans off all recently depleted token lists through calls to end_token_list (<324>). However, end_token_list puts align_state to zero if the finished token list was the u-part of an alignment template. Thus tab_marks become legal before the u-part has ended. If a tab_mark is produced from the macro, nothing is read into the # and the column ends with the v-part of the template. The remaining part of the expanded macro after the tab_mark is transferred to the next column (if that column does not perform the same trick). The trick was discovered when I wrote some macros for displaying equations, analogous to the LaTeX eqnarray environment but with an optional preamble description argument like the LaTeX array environment. Since it is rather cumbersome to keep track of the number of columns, the equation number was implemented as a zero width first column (with appropriate \hskip's for positioning). The first column ended itself with the above trick, which is convenient for the macro user, who does not have to put an additional tab_mark on every line. TeX did not complain, and at the time I was not surprised about that. Later on I started to worry: it might be a feature of the local TeX because the tab_marks were only allowed if the macro was at the end of the u_template. It turned out that excellent documentation was available, which prompted an attempt to find out if the trick should work in all TeX versions, with this inquiry as the result. Peter Wagemans Institute for Theoretical Physics P.O. Box 800 9700 AV Groningen The Netherlands EARN/BITNET address: WAGEMANS@HGRRUG5 ------------------------------ Date: Tue, 28 Apr 87 09:19:41 EST From: "S Bechtolsheim" To: texhax@score.stanford.edu Subject: Splitting tables Somebody asked for how you can split a header off a table, (sorry, I don't have the original message here). So here is an example of how this can be done: % \title: to generate some titles for our examples \def\title #1{ \vskip 20pt plus 5pt minus 3pt \centerline{\bf #1} \nobreak } % \scrollmode \splittopskip = 0pt \def\strut{\vrule height 8pt depth 4pt width 0pt} \showboxdepth = 1 \showboxbreadth = 200 % \vboxcen: generate a centered ($$ ... $$) \vbox % #1: content of the \vbox \def\vboxcen #1{ $$ \vbox{#1} $$ } % Build the original table here, and store in box register 0. \setbox 0 = \vbox { \offinterlineskip \tabskip = 10pt \halign{ \strut #\hfil& \hfil #\hfil\cr \it This is& \it the header\cr \it Header Line 2& \it more of it\cr L-1& Line 1 of table\cr L-2& Line 2 \dots\cr L-3& Some more stuff in Line 3\cr L-4& This is Line 4\cr L-5& More stuff\cr L-6& Even more stuff\cr L-7& The last line\cr } } \title{The original Table} \vboxcen{\copy 0} % \showbox 0 % Split of the header, 2 lines: (8 + 4) + 8 = 20. Result is in box reg. 2 \setbox 2 = \vsplit 0 to 20pt \title{The header} \vboxcen{\copy 2} % \showbox 0 % \showbox 2 \title{The rest of the table} \vboxcen{\copy 0} \title{Header and table lines together} \vboxcen{\copy 2 \copy 0} % Split of the first three rows of the table (result to register 4). % Dimension for \vsplit: (8+4) + (8+4) + 8 = 32 \setbox 4 = \vsplit 0 to 32pt \title{First three lines of the table itself} \vboxcen{\copy 4} \title{Rest} \vboxcen{\copy 0} \title{Header and first three lines of table} \vboxcen{ \copy 2 \copy 4 } \title{Header and remaining table lines} \vboxcen{ \copy 2 \copy 0 } \bye Stephan Bechtolsheim ------------------------------ Date: Tue, 28 Apr 87 10:36:23 PDT From: dual!dbi!stan@ucbvax.Berkeley.EDU To: dual!Score.Stanford.EDU!TeXhax Subject: metafont & fonts for LN03 Awhile ago Charles LaBrec posted a metafont definition for a "decln" printer mode for the Digital Equipment LN03 (a Ricoh 300dpi engine). Mr. LaBrec did not claim that his definition was correct only that it "seems to produce good 12 point cm fonts". He offered his definition as a starting point. His suggested definition of "decln" has now been included in a table of definitions in a short article by Barbara Beeton in the most recent TUGboat, Vol 8(1987) No. 1. The values of the definition are attributed to Mr. LaBrec, but his comments about how well he tested them are no longer included. Information about how well a particular definition is tested should be provided with any publication of the definition. I was not aware that someone was collecting metafont definitions for publications. My apologies for not getting this report out earlier. During late December and early January I made a CMR4 font for the LN03 using CMR5 and Mr. LaBrec's "decln" mode as a starting point. The "decln" mode he suggested did not fillin correctly and was too black for the smaller point sizes. His choice of settings produces small sized fonts that are much blacker than the small cmr's found in the cmr book (Vol E). After careful reading of the metafont book (Vol. C) and many tests using CMR5, CMR6, and CMR7, with only one value changed at a time, I found the following values of blacker and fillin to produce readable small fonts for an LN03: blacker:=0.2; % make things a bit blacker fillin:=-0.4; % darken diagonals These values were not carefully tested for larger point sizes. (I stopped experimenting when I got something I liked and I had verified that larger sizes were also usable.) Mr.LaBrec also made the comment that changing blacker, fillin, and o_correction had no effect over a large range of values. From my experience he must have been looking at the results of the changes using CMR12. Small changes are definitely noticeable when CMR5 is used instead of CMR12. Anyone interested in understanding these parameters should read the metafont book and experiment by setting sentences and paragraphs with many sizes of their new fonts. The look, blackness, readability, feel, taste, etc. of the variations of new fonts should be compared with the samples found in the cmr book. Stan, ...!ucbvax!dual!dbi!stan %%% %%% subscriptions, address changes to: texhax-request@score.stanford.edu %%% %%% submissions to: texhax@score.stanford.edu %%% %%%\bye %%% ------------------------------ End of TeXhax Digest **************************