phil@ux1.cso.uiuc.edu (07/18/90)
I major problem I run into frequently, for ANY text processing language or
system, be it TeX, Script, Scribe, *roff, or what.have.you, is that these
systems are not made easy to use from the point of view of someone who
does NOT write text in these languages, but just needs to print a text file
they received from someone.
With an ordinary programming language like C or Pascal, it turns out to be
relatively easy to take what someone gives you and compile it, load it, and
come up with a runnable program. I'm not a programmer of Pascal and never
will be, but yet I've had to compile programs in Pascal and this seems to
always be easy. It is made even easier with make.
With text formatting systems, it seems these things are always hard to do.
I recently received some files in the IBM SCRIPT language, and the SCRIPT
processing program would not process them. There was hundreds of error
messages. The SCRIPT expert here took two weeks to figure it all out and
finally get things set up so that the files were printable. She had to
do things with a number of files to make it work.
I have never used TeX before, but now I have occaision to need to USE it
from the point of view of simply getting a .tex file printed so I can read
it. I assume that's the point of sending files in .tex, so that they can
be printed and read. It is a document file for a program I received.
I read the TeX man page. It told me how to run TeX to create a DVI file.
Clearly more needed to be done, but there were no references to anything
else to do. It's as if all that people ever care to do is have DVI files.
Obviously there are questions I need to ask of those with more experience.
But in the past I have asked questions about specific cases, and got answers
that worked, but were so specific that they did not work when things were
changed somewhere. I need to be careful to ask things in a generic way so
that the answers are not only useful now, but I can adapt them in the future
as well, without having to go back and ask similar questions over and over.
I have some books on TeX, from back when I was thinking about learning how
to write in the formatting language. Lacking a program to process it then,
I never picked it up. But these books deal with the problems of writing in
the language, not with processing and printing an already written TeX file
that was given to me. Perhaps that is in there as well, but it is not
obvious from scanning the contents or index.
So what I am looking for now is NOT what I need to do to print my files,
but rather some general purpose information that tells me enough about how
the parts of TeX fit together so that I can figure out how to get the .tex
files I have printed.
One thing I notice is that there are usually lots of vast macros written
for many text formatting languages. Apparently it is a practice to ASSUME
that everyone has every macro. Is this a valid assumption with TeX? If it
is, then the macros are public domain. I suspect not, but I could be wrong.
What are the various macro libraries available? How do I use them (from the
point of view of getting the .tex document printed, no in writing in TeX)?
It seems modularity has its disadvantages as well. I program in macro
assembler language a lot, and find that when I send someone a program, I
frequently have to send them dozens of macros to go with it (most of which
I wrote, the rest of which are still not common anyway). Is this (sending
macros with .tex) common in exchanging documents in TeX?
I simply ran the tex command giving it the name of one of the files I need
printed, and it said:
! undefined control sequence.
l.5 \documentstyle
[makeidx]{article}
?
and it seemed to be waiting for my input. I killed the program and gave up.
What in general needs to be done here? Surely there is not really an error
in the .tex file, is there?
The next step is that I will end up with a DVI file (I assume a file with
and extension of .dvi). This I understood from the man page for tex. But
it did not say what do to with the dvi file. I tried "man dvi" but there
was no such man page. So, what do I do with a .dvi file? Also, is there
any documentation on what the format of a .dvi file is? And if a DVI file
is truly device independent, why isn't the .dvi file exchanged instead of
the .tex file? I know; I might want to modify the document for some reason
and a .dvi is not (easily) human readable (much like the machine language
object code output of a compiler).
Thanks in advance for any generally useful information anyone might be able
to post and/or send me about what TeX is all about and how to use it.
--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.dhosek@sif.claremont.edu (Hosek, Donald A.) (07/18/90)
In article <1048100001@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes... >I have never used TeX before, but now I have occaision to need to USE it >from the point of view of simply getting a .tex file printed so I can read >it. I assume that's the point of sending files in .tex, so that they can >be printed and read. It is a document file for a program I received. >I read the TeX man page. It told me how to run TeX to create a DVI file. >Clearly more needed to be done, but there were no references to anything >else to do. It's as if all that people ever care to do is have DVI files. Well, the reason for this is that there are jillions of DVI-to-whatever converters available. Not all of them work the same (for example, on our VMS system, to print pages 3-5 of foo.dvi, I would type dviout foo/pages=3:5 while on our Unix system, the command is dvialw -o3:5 foo) and certainly they all have different names. Plus, different sites might configure things differently. Here at HMC, the DVI processors create a file to be printed in a separate step. At UIC where I worked once upon a time, all DVI processing was bundled into a program "PRINTTEX" which would select the printer driver and handle converting options to the format the driver wanted and print the output when it was done). The reason most of the documentation doesn't mention these things is that it is usually quite different between sites. >One thing I notice is that there are usually lots of vast macros written >for many text formatting languages. Apparently it is a practice to ASSUME >that everyone has every macro. Is this a valid assumption with TeX? If it >is, then the macros are public domain. I suspect not, but I could be wrong. >What are the various macro libraries available? How do I use them (from the >point of view of getting the .tex document printed, no in writing in TeX)? >It seems modularity has its disadvantages as well. I program in macro >assembler language a lot, and find that when I send someone a program, I >frequently have to send them dozens of macros to go with it (most of which >I wrote, the rest of which are still not common anyway). Is this (sending >macros with .tex) common in exchanging documents in TeX? Yep. LaTeX users (at least intelligent ones) can generally avoid this problem. >I simply ran the tex command giving it the name of one of the files I need >printed, and it said: >! undefined control sequence. >l.5 \documentstyle > [makeidx]{article} >? Any document which begins with \documentstyle is a LaTeX file. Rather than saying "tex filename" you need to say "latex filename". Just one of life's inconveniences. >The next step is that I will end up with a DVI file (I assume a file with >and extension of .dvi). This I understood from the man page for tex. But >it did not say what do to with the dvi file. I tried "man dvi" but there >was no such man page. Try typing "apropos dvi" and see what you get ("apropos DVI" might also be worth a shot). >And if a DVI file >is truly device independent, why isn't the .dvi file exchanged instead of >the .tex file? I know; I might want to modify the document for some reason >and a .dvi is not (easily) human readable (much like the machine language >object code output of a compiler). Ever try moving binary files between machines? There are a lot of bugbears lying around to trip one up. MVS, CMS and VMS all require special system-dependent blocking. You can't e-mail a binary file (easily) etc. -dh --- Don Hosek TeX, LaTeX, and Metafont Consulting and dhosek@ymir.claremont.edu production work. Free Estimates. dhosek@ymir.bitnet uunet!jarthur!ymir Phone: 714-625-0147
jacob@gore.com (Jacob Gore) (07/18/90)
In article <1048100001@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes... >And if a DVI file >is truly device independent, why isn't the .dvi file exchanged instead of >the .tex file? I know; I might want to modify the document for some reason >and a .dvi is not (easily) human readable (much like the machine language >object code output of a compiler). / comp.text.tex / dhosek@sif.claremont.edu (Hosek, Donald A.) / Jul 17, 1990 / > Ever try moving binary files between machines? There are a lot of > bugbears lying around to trip one up. MVS, CMS and VMS all require > special system-dependent blocking. You can't e-mail a binary file > (easily) etc. Even if these weren't a problem, it's still unreliable to ship .dvi files. The device they are independent from is the output device, not the computer. In particular, a .dvi file has been created with a particular set of fonts in mind, and those fonts may not be available on another system. For example, on machine A the nominal "18-point Computer Modern Roman font" may be cmr18, while on machine B it may be cmr10 scaled to 18 points. If I try to print from B a .dvi file created on A, the spacing will be screwed up. And people at site C may prefer not to use Computer Modern fonts at all, and substitute Times-Roman-18 -- no problem if they have the source, impossible if they just have the binary. It's much better to ship the sources. Now within one system, you do get device independence: with appropriate dvi-to-output-device programs (and font pixel files at appropriate resolutions), the same .dvi file can be sent to a Postscript printer; a ImPRESS printer; a LaserJet PCL printer; a NextStep, X, SunTools, MS Windows or EGA previewer; etc., etc., etc... Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
miller@cam.nist.gov (Bruce R. Miller) (07/18/90)
In article <1048100001@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes: > ... > With an ordinary programming language like C or Pascal, it turns out to be > relatively easy to take what someone gives you and compile it, load it, and > come up with a runnable program. I'm not a programmer of Pascal and never > will be, but yet I've had to compile programs in Pascal and this seems to > always be easy. It is made even easier with make. > > With text formatting systems, it seems these things are always hard to do. I'ld just say you've been luckier with programming languages so far -- even with make. I think you are probably more likely to run into portability problems with regular programs than something like TeX; TeX is defined more independently of OS's, hardware etc. One result is that it produces `Device independent' output, which, as you discovered, forces you to find the OS & hardware dependent way to turn it to postscript, hp-language or dots and print it! Also, I think that most often people sending out .c .pas .lisp .tex .fubar are implicitly expecting that the recipient knows c, pascal ... Most of your questions were well answered by In article <7854@jarthur.Claremont.EDU>, Hosek, Donald A. writes: > In article <1048100001@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes... > > > .... Is this (sending > >macros with .tex) common in exchanging documents in TeX? > > Yep. LaTeX users (at least intelligent ones) can generally avoid > this problem. Educate me! This is a problem I've always run into with sending & recieving (La)TeX files. With make or defsystem you have a clear indication of what files are needed; so you know what needs to be sent. No, I take that back, even then with c at least, the header files are hidden in the sources analogously to TeX \input's and are seldom (?) mentioned in make files. (Lisp defsystem's are a bit better: they provide information to be used for compiling, loading, distributing, hardcopying...) Anyway, any tex file I've written or recieved has ALWAYS got a couple of \input's of sundry macro's and tools, and occasionally a special .sty [Like Phil's example BTW !] I always put these at the very top, IMMEDIATELY after \documentstyle, so they're easy to find; But they still have to be LOOKed for! and they occasionally get missed. People who've sent me TeX aren't always quite as `organized'. Is this what you're suggesting or do you have a better model? Another problem is you've got to avoid having any directory names on included files. Luckily with the Unix C version I can add to a TeX `path' so I can use macros from a ~/TeX/ directory wherever my doc is, but with other versions I used, this wasnt possible. And if you are using any \specials to include postscript graphics, even when you know the other people are using postscript this creates problems to find all the extra files that need to be sent. This is getting abit far from the original question, but any Suggestions? Bruce
mdeck@acsu.buffalo.edu (Mary Deck) (07/19/90)
In article <1048100001@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes: > > [...] >With an ordinary programming language like C or Pascal, it turns out to be >relatively easy to take what someone gives you and compile it, load it, and >come up with a runnable program. I'm not a programmer of Pascal and never >will be, but yet I've had to compile programs in Pascal and this seems to >always be easy. It is made even easier with make. How hard would it be for you to figure out what to do with a program written in any programming language if you didn't know what a compiler was, or perhaps didn't know that you had to link it before it would run? Odds are, you wouldn't have any idea where to look for information, or what to start looking for. TeX is no different. It's just like any process: If you don't have enough basic information, you aren't going to be able to do anything useful. But if you have enough information to take advantage of the whole thing, you'll be worlds better off. (My point: Don't pick on TeX. It's bigger than you. :) > [...] >One thing I notice is that there are usually lots of vast macros written >for many text formatting languages. Apparently it is a practice to ASSUME >that everyone has every macro. Is this a valid assumption with TeX? If it >is, then the macros are public domain. I suspect not, but I could be wrong. >What are the various macro libraries available? How do I use them (from the >point of view of getting the .tex document printed, no in writing in TeX)? One of the great things about TeX is that the really useful parts of it are available by anonymous FTP (from several sites, for many different computers), including all the 'standard' macro packages (which are labeled as such). You *can* get it for free, and what you get will be useful and complete. All you have to do is know what to get, where to get it from, and what to do with it once you get it. It's a learning process which I haven't finished, or I'd gladly tell you everything. :) Another really nice thing about TeX is that a lot of places use it. It's well tested and well supported, besides being an "industry standard." It's also very flexible, and you can make it do what you want it to, given the knowledge, sufficient time and the will to make it work. ....Mary * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Mary M. Deck Student Assistant, Software Development State University of New York at Buffalo acsgmmd@ubvms.cc.buffalo.edu [VAX/VMS] mdeck@cs.buffalo.edu [UNIX] "I'm a lowly undergraduate. I'm overworked and underpaid. I represent no one but myself." -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Mary M. Deck Student Assistant, Software Development State University of New York at Buffalo
mfb@super.ORG (Michael F. Bridgland) (07/19/90)
In article <7854@jarthur.Claremont.EDU> dhosek@sif.claremont.edu writes: >In article <1048100001@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes... > >>I have never used TeX before, but now I have occaision to need to USE it >>from the point of view of simply getting a .tex file printed so I can read >>it. I assume that's the point of sending files in .tex, so that they can >>be printed and read. It is a document file for a program I received. > >>I read the TeX man page. It told me how to run TeX to create a DVI file. >>Clearly more needed to be done, but there were no references to anything >>else to do. It's as if all that people ever care to do is have DVI files. > >Well, the reason for this is that there are jillions of >DVI-to-whatever converters available. Not all of them work the >same (for example, on our VMS system, to print pages 3-5 of >foo.dvi, I would type dviout foo/pages=3:5 while on our Unix >system, the command is dvialw -o3:5 foo) and certainly they all >have different names. Plus, different sites might configure >things differently. Here at HMC, the DVI processors create a file >to be printed in a separate step. At UIC where I worked once upon >a time, all DVI processing was bundled into a program "PRINTTEX" >which would select the printer driver and handle converting >options to the format the driver wanted and print the output when >it was done). The reason most of the documentation doesn't >mention these things is that it is usually quite different >between sites. Nonetheless, the point made in the original posting is a valid one. The man page for tex should at the very least refer the reader to other man pages describing the commands used at the site to preview dvi files and to produce hardcopy. Of course, the absence of such documentation is not a problem with tex per se, but with the ignorance, laziness, arrogance, etc., of the local installer. > >>One thing I notice is that there are usually lots of vast macros written >>for many text formatting languages. Apparently it is a practice to ASSUME >>that everyone has every macro. Is this a valid assumption with TeX? If it >>is, then the macros are public domain. I suspect not, but I could be wrong. >>What are the various macro libraries available? How do I use them (from the >>point of view of getting the .tex document printed, no in writing in TeX)? >>It seems modularity has its disadvantages as well. I program in macro >>assembler language a lot, and find that when I send someone a program, I >>frequently have to send them dozens of macros to go with it (most of which >>I wrote, the rest of which are still not common anyway). Is this (sending >>macros with .tex) common in exchanging documents in TeX? > >Yep. LaTeX users (at least intelligent ones) can generally avoid >this problem. > >>I simply ran the tex command giving it the name of one of the files I need >>printed, and it said: > >>! undefined control sequence. >>l.5 \documentstyle >> [makeidx]{article} >>? > >Any document which begins with \documentstyle is a LaTeX file. That is not true. For example, a document beginning with \documentstyle{amsppt} is virtually certain to be an AmS-TeX file. >Rather than saying "tex filename" you need to say "latex >filename". Just one of life's inconveniences. > Again, the point made in the original posting is valid. The person sending the file should have told the recipient the nature of the file. Every tex file distributed for use by unknown others should include some introductory comments about how the file is intended to be used. It isn't as if this were any great burden on the creator of the file. Recently, I have been sending a fair amount of e-mail devoted to mathematical discussions. Rather than fight with the notational inadequacies of ascii text, I use AmS-TeX. Since the people with whom I correspond have some familiarity with AmS-TeX, they may simply read the tex source I send. Nonetheless, I begin each message with the following header: %% For an easier-to-read version, %% save this note, less the mailer header, as (e.g.) note.tex %% Then embed it in an amstex file as follows. %% Then tex it. I always try to write mathematical e-mail so that %% it will TeX successfully if treated this way. %% %% \input amstex %if necessary %% \documentstyle{amsppt} %% \topmatter %% \endtopmatter %% \document %% \input note %% \enddocument %% Now the cognoscenti will know that they can safely leave out the line \input amstex and invoke the command amstex instead of tex. But my header does not demand that the reader be among the cognoscenti. --Mike Bridgland