1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
ANNOUNCING THE OFFICIAL RELEASE OF VTPRINT 2.0!
===============================================
June 19, 1994
Finally, I have finished putting the last touches on the vtprint-2.0
package. It is now ready for general consumption. If you are using
an earlier version of vtprint, I strongly recommend you to upgrade now!
vtprint 2.0 is a complete rewrite from the 1.x versions.
vtprint is a program that allows users to print from a remote UNIX host
to a printer attached to their local terminal or emulator, which makes
it great for printing files at home, etc. (It only does text files, though.)
vtprint is available via anonymous ftp from ftp.sdsu.edu in the /pub/vtprint
directory. It is also available by uuencoded e-mail by sending a request
to the author at <garrett@sciences.sdsu.edu>. NOTE THAT FTP.NETCOM.COM
IS NO LONGER THE OFFICIAL SITE FOR VTPRINT -- the files stored there are
likely to old -- use ftp.sdsu.edu instead!
vtprint should be fully portable to any modern UNIX. The only "difficult"
things are likely to be a need for an ANSI C compiler and GNU gzip. (gzip
is used to decompress the package, and is available from prep.ai.mit.edu
via anonymous ftp in the /pub/gnu directory.)
Attached below is the WHATSNEW file for those of you already using
vtprint:
=======> cut here <========
What's new in vtprint 2.0 from 1.x?
vtprint-2.0 represents a *complete* rewrite of vtprint. I decided to change
somewhat the design philosophy, deeming portability to non-UNIX systems to
be really worthless. Hence, this is probably only compilable on UNIX or
UNIX-clone systems. Also, I moved to the "getopt()" facility which
simplified some of the option parsing code.
Here's a list of some of the "user-visible" additions to vtprint:
1) support for any *terminal* with printer control codes via
an external library file (see vtprintcap(5).)
2) support for CR/LF handling directly
3) support for output to *any* device file via the command line.
4) support for "session defaults" via an environmental variable
which can hold command-line options.
5) optional "binary" mode, overriding CR/LF translations (can only
be used on terminal devices).
6) probably other things I can't think of now.
=================================================================
Garrett D'Amore | garrett@sciences.sdsu.edu
Student Programmer/Analyst | SDSU College of Sciences
SDSU Computer Science Major | Physics Bldg., Room 238
=================================================================
|
