[comp.lang.postscript] Automatic posting v 2

woody@rpp386.cactus.org (Woodrow Baker) (03/05/90)

Here is a much revised version.  Many thanks to all.  I expect a couple
more drafts at the very most.
There have been many good comments.  I have some questions about FTP and
non ftp sites for certain programs.  When I find the info, I'll replace
them with the info.

Automatic posting
This posting is brought to you by
 
Woody Baker
Rt.1 Box I
Manor, Tx. 78653
 
woody@rpp386
 
This is the second draft.
 
Many thanks to the good folk who contributed their time to looking this
over.  Don Hopkins supplied a lot of suggestions, many of which have been
incorporated. It has been suggested by Mark Isaak that the post be split
into the text and a program block, rather than just the combined file.
I think I'll put  together a program posting as well.  Some suggested
things to include:
 
        Run length encoding and decoding
        lineprinter text to postscript (included here, but could be expanded)
        simple calendar program (i.e. short)
        code to print n * m pages on a page
        A point ruler
        A protractor
        A graph paper generator
        Code to change the page size. (Amanda has a nice one)
        
        
        I'd welcome additions to this list.  If you have the code to
        handle the addition, please send it along.
        
David Cortesi has to be an English teacher, or an Editor!  I ran it through 
a spell checker, but did not run it through my grammar checker.  David is 
probably better than the grammar checker....thanks...8-}
 
Many thanks to the folk who pointed out the massive gaffe >B-{ !  It
seems that while I was working on this, early in the morning, I forgot
the { } around the redefinitions of the key words in the optimization
portion.  Ugggg!
 
This posting was developed to answer routine questions. If your question
falls under one of the listed questions below, you likely will find the 
answer here.  Please read the post before posting the question.  This has
2 benefits.  The first is that your question gets answered faster.  The 
second one is that it reduces traffic on the group.
 
NOTE: THIS IS A LONG FILE!  There are a lot of questions and information.
 
What are the best books to buy to learn about PostScript?
What are the "colored books", and where can I get them?
How can I speed up printing?
Why doesn't the hi bit get through?
How can I compress data so it transmits faster?
How can I convert PostScript to bitmaps, and How can I get bit maps 
        back from the printer?
How can I convert PostScript to GIF?        
What is exitserver and why does it cause errors on some systems?
How can I print MAC files on a non Apple printer?
How can I print non-MAC files on the MAC?        
How can I access the file server at Adobe?
Where and how can I access PD fonts?
Where can I get info about the color operators and language extensions?
What is EPS and where can I get information on it?
What are dictionaries and how do they work?
How can I turn on HPLJET emulation?
What debugging tools are available?
Where can I get interpreters/previewers?
How can I emulate HPGL?
How can I convert ASCII to Postscript?
What coding styles are in general use and which shall I use?
 
 
What are the best books to buy to learn about PostScript?
 
The "colored" books.
 
What are the "colored" books?
 
These books are the fundamental information on PostScript.  They should be on
EVERY PostScript programmer's bookshelf or desktop.  They are nicknamed for
their jacket colors.  Any good bookstore should have them.  Here in Austin,
they are available at BookStop and Walden or B.Dalton booksellers.  With
the information below they can be ordered from any bookstore.  I believe that
they can be gotten directly from Adobe.  Don Lancaster stocks them as well.
He advertises in the Computer Shopper.  His number is 602-428-4073.  QMS
USED to ship the RED and BLUE books with each printer, but sadly, they have
quit doing that several years ago.
 
RED BOOK        PostScript Language Reference Manual
                Adobe.  Publisher: Addison-Wesley
                ISBN 0-201-10174-2
                LC# QA76.73.P67P67
                
BLUE BOOK        PostScript Tutorial and Cookbook
                Adobe.  Publisher: Addison-Wesley
                ISBN 0-201-10179-3
                LC# QA76.73.P67P68
                
GREEN BOOK        PostScript Language Program Design
                Adobe.        Publisher: Addison-Wesley
                ISBN 0-201-14396-8
                LC# QA?????
                
ORANGE BOOK        Real World PostScript
                Stephen F. Roth editor  Publisher: Addison-Wesley
                ISBN 0-201-06663-7
                LC# Z286.D47R4 1988
                
Printer Supplement.  Usually shipped with each printer.  Covers special
features, and setup operators of that particular printer.
 
The beginning PostScript programmer should read the GREEN book first with the
RED book handy as reference.  Some programmers don't like the coding style 
used in the GREEN book, but the important thing is to make your code clear,
readable and maintainable. Next read the BLUE book, again with the RED
book as a reference.  The ORANGE book is a collection of articles
dealing with the real world, and specific applications such as font creation,
color separation, kerning, halftoning and various other topics.        
 
The BLUE book has a problem with many of the examples.  One that recently
caused a question was the  circletext routine.
 
The font used to set the programs in the BLUE book is Helvetica.  It is easy 
to mistake ( ) for ()  That is, it looks like () but should be ( ).
 
How can I speed printing up?
 
There are actually 2 issues here.
        1.        Throughput of the comm channel
        2.        The way the code is written
        
1a.        Serial
 
Versions 38.0 and greater of Adobe printers, allow the baudrate to be set up.
The code fragments below illustrate this.  The baud rate can be set as high as
57,600 baud.  There are people successfully using 19200, and 38400.  These
seem to be rather common.  Don Lancaster uses 57,600 baud for ONE WAY
printing with no return messages. He can shed further light on it.  Call 
him at 602-428-4073.  He is very helpful.  He publishes his phone number
in the Computer Shopper in his PostScript column, and offers free help,
along with lots of software, books etc. (which are not free)
 
Remember that position 1 is ALWAYS 1200 baud PostScript, so that you can
recover if you mess up.  Usually this is a thumb wheel, pushbutton, or
dip switch located on the printer.  The printer supplement will cover this.
You MUST get your handshaking right for baudrates like these.  The PC 
class machines running MS-DOS don't understand XON/XOFF without some
kind of spooler or driver.  I like Superspl from AST.  It works.
 
The high bit gets killed by the serial port.
 
1b.        Parallel
 
Use it if you have it.  It is generally much faster.  The return channel
will be the 9 pin serial port.  It must be setup to the correct baudrate
if you are going to use it.  The return channel is used to send messages
back to the computer.  If you are working with a straight serial connection
the return channel and the sending channel are the same.  But since 
parallel is unidirectional, the 9 pin serial channel is used to return
messages
 
The following code shows how to set baud rates up for 19200, and how to
set the handshaking up for DTR/DSR or XON/XOFF.
 
example code.  Refer to your printer supplement for what works on your 
printer.
 
%
% set handshaking to dtr
%
statusdict begin 
25 sccbatch exch pop 4 eq 
                          {
                          stop % if already set, then leave it
                          } if
serverdict begin 0 exitserver
statusdict begin 25 19200 4 setsccbatch 
%
% set handshaking to XON/XOFF
%
statusdict begin 
25 sccbatch exch pop 0 eq 
                        {
                        stop
                        } if
serverdict begin 0 exitserver
statusdict begin 25 19200 0 setsccbatch 
%
% tell us which handshaking mode we are set to.
%
/Times-Roman findfont 20 scalefont setfont
100 300 moveto
(Serial flow control is now )show
statusdict begin 
25 sccbatch exch pop 4 lt 
                        {
                        (xon/xoff)
                        }
                        {
                        (dst/dtr)
                        }ifelse 
                show
showpage
 
 
2.        Coding
Postscript code can be shortened.  This speeds PostScript up in two ways:
by reducing transmission time (fewer bytes to transmit) and by reducing
the time that the interpreter takes to process the file.  
Generally for simple stuff, transmission time is the bottleneck.  
The basic transmission reduction optimization involves shortening the 
PostScript commands to 1 or 2 letter commands.
 
The most common definitions
 
/l {lineto} def         /ff  {findfont} def        /GS {gsave} def
/m {moveto} def         /sf  {setfont} def        /GR {grestore} def
/c {curveto} def /SP  {showpage} def        /f  {fill} def
/s {scale} def         /rm  {rmoveto} def        /SG {setgray} def
/SH {show} def         /rl  {rlineto} def        /MF {makefont} def
/st {stroke} def /rc  {rcurveto} def        /SF {scalefont} def        
 
It also helps to reduce the font names.  The scheme most generally used
is to create an abbreviation of the font name, and tack on one of the
following "suffixes"  B --Bold  BO --BoldOblique  BI --BoldItalic
O --Oblique   I --Italic  and <space> for normal.
 
/H   {Helvetica} def
/HB  {Helvetica-Bold} def
/HBO {Helvetica-BoldOblique} def
/HO  {Helvetica-Oblique} def
 
Then you can do the following, for example:
 
H ff 10 SF sf
 
versus
 
/Helvetica findfont 10 scalefont setfont
 
 
Speeding execution up.
 
The most commonly overlooked technique is to use bind def, rather than just
def for procedure names.  The reason for the speed up, is that the 
interpreter replaces the name in the internals with a pointer to the routine
and thus does not have to scan tables or dictionaries looking for a
name.  Consult the RED and GREEN books for further information on this
topic. The second way to speed things up is related.  Leave as much stuff
on the stack as possible, rather than using variables.  The GREEN book
has an especially lucid treatment of this. The downside of this
is that it makes the code EXTREMELY difficult to follow and debug.  This has
also been hashed over.  It is easier to maintain code that has everything
held in variables, but you pay a time penalty for doing so.  Leaving
intermediate values on the stack tends to obfuscate the code, but does 
increase speed of execution.
 
Data compression has been discussed at length.  It may or may not help you
depending on the type of data and speed of printers execution of the 
uncompression routine.  It can be slower than uncompressed data in total 
throughput.  There have been several compression routines posted, including
one that handles RLL compressed files..
 
Putting repetitive  blocks into a font, and using the cache can dramatically
speed things up.  This technique is covered in the RED and BLUE books in
a limited sort of way.  To do this, you have to define a font, and then
define the repetitive block as a character.  For example, if you want to
draw lots of boxes or triangles or squares, build a font like the Analytical
font in the BLUE book.  You can put almost anything into a font if you
follow the rules carefully. 
 
How can I convert PostScript code to a bitmap?
 
You have several choice at the moment.  One of the commercial computer 
resident PostScript interpreters such as Ultrascript, Goscript and 
Freedom of the Press will do it.   NeWS does it.  Display Postscript
does it also.  Lasertalk has a routine that dumps the bit map back up the 
serial link.  They licensed it from Adobe.  All attempts to get Adobe 
to turn loose of it have failed.  Since Display PostScript allows the capture
 of bit map screens, it seems inconsistent to not provide the routine
for the printer, but that is currently the way it is. 
 
How can I convert PostScript to GIF?
 
One way:
        Use Ultrascript pc to convert to a PCX file
        use BIT2GRAY to condense the PCX file to a smaller one
        use VPIC to convert to GIF.
        Now: Where can these be found?
 
What is exitserver and why does it create error messages?
 
The PostScript interpreter is a loop.  The exit server command causes
this loop to be exited.  Since the loop is bracketed by a save/restore
context, and a stopped context, it means that it normally retains control.
It also cleans up Virtual Memory (VM) after each job.  For something to
stay around during the cleanup (via the restore), you have to insert it
into VM outside of the context of the save/restore.  The exitserver
command does this.  There is a password needed to execute the exitserver
command.  Many applications depend on downloaded preambles being present and
so they attempt to exit the server.  The password can be changed.  On 
network printers, typically this is done to protect the integrity of the
printers preambles, etc.  If you don't know the password, exit server will
fail.  Most apps that do this assume the default password.  There is a
way around this.  There exists a password resetter/reader program.  It is 
available under the following conditions:
 
A letter requesting it, on Department or Company letterhead, (LASER PRINTED
IS NOT GOING TO CUT IT. 8-}..) and signed by a responsible party, department
head, company officer etc, should be sent to me.  An email message should
also be sent so I'll know where to mail the routine.  The reason for this,
is that the routine can be used to really mess the printer up.  It can also
be used to unmess the printer.  Therefore, in a network environment, it should
remain in the administrators hands.  I don't want fingers pointed at me, when
someone misuses it.
 
Send the letter to:
 
Woody Baker
Rt.1 Box I
Manor, Tx. 78653
 
How can I print MAC files on a non-Apple printer?
How can I print non MAC files from the mac?
 
You will need to get the files to the mac first.  If they are just
straight PostScript, you should be able to send them to the printer directly.
Not having much MAC experience, the only way that I currently know is using
sendps.  If your non-Apple Printer has APPLETALK, use it.  If not, then you
will have to transmit the data on the serial port to the printer.
 
Further topics are going to depend on the following info, so:
 
How to access the file server at Adobe.
 
mail  ps-file-server@adobe.COM
 
send help     ....will get you a copy of the instructions
send Index    ....Will get you a copy of the index
send Index Documents  ...Will get you a copy of the Documents index
send Documents "name" ...Will get you "name" document.
 
There is a copyrighted chess font called CHEQUE on the Adobe server.  It
will send it to you if asked.
 
Please read the help file first.
 
Where can I get public domain fonts?
 
mail font-server@mims-iris.waterloo.edu
 
send help        ....same as above
send Index        ....same as above
send util CONTENTS .Gets you the contents list of the postscript font 
                   directory
 
NOTE:  There are some restrictions, so read the  help file, and then
send for README.1st.......
 
Where can I get info about the color operators and language extensions?
 
from the Adobe file server.
 
What is encapsulated postscript and where can I get information on it?
 
The Adobe file server has a complete set of specs on EPS.  It will
happily send it to you on request.  Unfortunately, EPS is not quite as
standard as it should be.  Applications can claim EPS compatibility and
NOT be able to use EPS files from other apps.  This is generally the fault
of the apps.  All it takes is a subset of EPS to be "compliant".  Certain 
applications depend on this-n-that piece of information to be present in 
an EPS file.  If it isn't, it can't use the EPS file.  The MAC apps seem to 
be the worst offender.  You can capture a file going to the printer from 
the MAC keyboard using COMMAND K but then you need to 
edit it to even get it to print.  There is a program floating around 
called MacPS that does this cleanup for you.  There are lines dealing with 
setdefaulttimeouts and sccinteractive that must be commented out.  There 
are also 2 flushfile's that cause problems. The best thing to do is to get 
MacPS.  I currently don't know where to find it on the net, but I'll be glad
to update this if someone will point me to it.  I want both an ftp site 
and a NON ftp site, preferably a server.
 
Dictionaries:
 
These seem to be a hard concept for many people to grasp.  They were very
difficult for me, and since several people have asked how they work, a
short discussion of them is included. My own personal model is a keyed
random access file.  I tend to think of dictionaries as an overlay file that
is keyed, and carries it's data with it. I can open and load it (begin), 
close and quit (end).  I can also index through it, look things up in it
and get things from it.  The contents DON'T go away.  The dictionary and 
variables stay around in memory and can be opened or put on the dictionary 
stack and used at any time.  Admittedly, this may not be the best model
but it works for me.
 
How can I turn HPLASERJET emulation on?
 
This is somewhat printer dependent.  Most Adobe version 47 printers have it
and some Adobe version 42 printers have it.  It is supported on the QMS
line of printers, and on the newer Apple printers. Dumping the internal 
dictionaries in interactive mode and examining the contents is the way 
to find out how to do it.
 
In general, there is an array of procedures that handles the switch(s) on
the printer.  There is 1 routine per switch setting.  The newer printers
have  exechplj  exchpgl and diabloexec defined in general.  These handle
everything needed to start the emulator.  HOWEVER:  doing so from PostScript
will leave PostScript in charge of the serial port.  You will then have to
enable cr/lf for the printer, as PostScript unfortunately converts CR/LF
pairs into simple lf's.  For the HP, you must send  ESC &k3G  .  Control
D will exit you.  In some implementations, you can exit from the switch
selected mode, or so I've been told, with ESC 7f 04.  On some printers
there is also a sethardwareiomode and setsoftwareiomode that deal with 
this problem.
 
The serial port under PostScript is a non-transparent 7 bit rather than
standard 8 bit port.  This basically keeps HP graphics stuff out.  
Short of a machine language patch, there will be no way 
to get 8 bits down the serial link to PostScript.  In addition
you can't get certain control codes such as ^T, ^S, ^C, and ^D through.  
Parallel is not quite so hamstrung.
 
What tools are available for debugging PostScript?
 
Depending on your system:
 
erhandler.ps from Adobe file server is a downloaded page-printing 
errorhandler.  I could not get along without it.
MAC-Lasertalk among others
PC -Lasertalk 
NeWS 1.1 or X11/NeWS from SUN. PSIBER takes advantage of the debugger
(debug.ps) that comes with NeWS and is documented in the NeWS manual.
PSIBER and debug.ps only work with NeWS, not Display PostScript or 
PostScript in a printer.
 
imagetops, fbps are also available.  
XPS is an interpreter for X
 
Where can I get a copy of a PostScript previewer/interpreter?
 
Crispin Goswell from Rutherford Labs, over in England has posted the
source for one that runs on the SUN.  It is not a simple project to get
running.  I have the source, which I got off a local bbs.  See the end of
the post on how to get it.  I don't currently know of any sites that have
an interpreter, but if someone does, let me know.  Again, both FTP and NON
FTP sites are sought.
 
How can I translate PostScript to HPGL/HPGL to PostScript?
 
Some printers, notably the QMS series have an HPGL emulator built into them.
Currently, that is the only way that I know of.
 
 
 
How can I translate ASCII text to PostScript?
 
There are two ways.  Some Adobe printers have Diablo emulation, and
some add HPLJET+ emulation.  These can usually be turned on under software
control. 
 
The other, involves a downloaded printer "emulator"
 
There have been several utilities posted for this.  The most comprehensive
one is:
 
%
%
%!-Adobe-1.0
%%Title: asciiprint.ps
%%Creator: Ben Cranston <zben@umd2.umd.edu>
%%CreationDate: Thu Feb 8 1990
%%Pages 0
 
/Courier findfont 10 scalefont setfont
/colwid (m) stringwidth pop def
36 756 moveto
256 string
{ %exec
   { %loop over file
      dup currentfile exch readstring exch
      { %loop FF
         (\f) search exch
         { %loop LF
            (\n) search exch
            { %loop CR
               (\r) search exch
               { %loop TAB
                  (\t) search exch
                  { %loop BS
                     (\b) search exch
                     show
                     not { exit } if
                     pop currentpoint exch colwid sub exch moveto
                  } loop %BS
                  not { exit } if
                  pop currentpoint exch 36 sub colwid div .49 add cvi
                  8 add dup 8 mod sub colwid mul 36 add exch moveto
               } loop %TAB
               not { exit } if
               pop 36 currentpoint exch pop moveto
            } loop %CR
            not { exit } if
            pop 36 currentpoint exch pop
            11 sub dup 25 le { %if
               pop showpage 756
            } if
            moveto
         } loop %LF
         not { exit } if
         pop showpage 36 756 moveto
      } loop %FF
      not { exit } if
   } loop %over file
   pop showpage
} bind exec
 
The following came from the author's original posting.
 
The tab code has been changed to make it more readable and modifiable.
The two 8s are the tab stops, you should be able to change them to any
other number.  The only other change is the indentation at three should
be a tad more readable than the old indentation at two.
 
1. FF (form feed) causes a break to the first character position on a new
page.  If FF is given at the very end of a file a blank page is produced.
2. LF (line feed) causes a break to the first character position of a new
line of the page, except when that would be below a certain point, in which
case a break to the top of the next page occurs instead (unmarked "if").
3. CR (carriage return) causes a break back to the first character position
of the CURRENT line.  
4. TAB (horizontal tab) causes a break to the next multiple of 8 characters
from the left margin.  The magic constant 248 is 0xF8 which throws away the
bottom 7 bits.  The tab spacing could probably be changed if one were to
make the appropriate adjustment to this number.
5. BS (backspace) causes the print position to move one character width back
to the left. 
 
A simple one can be found in the GREEN book, but it operates in line mode
like a teletype almost.
 
/buff 128 string def
/emulate
        {
                {
                currentfile buff readstring
                exch show not
                        {
                        exit
                        } if
                } loop
        showpage
        } bind def
%
% usage
%
72 750 moveto /Courier findfont 10 scalefont setfont emulate
 
text follows to be printed.  Each line will be isolated when a NEWLINE
is encountered, and then printed.                        
 
 
What style should I use?
 
First off:
An example of what NOT to do:
 
/procedurename {
body }def
variable 0 eq {
conditionbody }{
conditionbody
}ifelse        
 
or 
 
/procedurename {body}def variable 0 eq { conditionbody}
{conditionbody} ifelse morebody and conditions etc.etc.
 
Opinions voiced on this topic generally ignite a raging fire-fight.  
There are several basic coding styles, and the general consensus is 
that you should be clear, consistent and easy to read and maintain.
Compactness seems to be very desirable to a large number of people.
Indention levels are the most important feature.  Improper indention
can lead to all sorts of problems.  
  
Most of these styles are also shared with 'C'.
 
Style 1.        Probably the most general style.  Similar to styles used
                in most other free form languages such as PASCAL, MODULA II,
                BASIC and 'C'. Familiar to most of the population in general.  
/procedurename
        {
          body
        } def
        
        variable 0 eq
                {
                 condition body
                }
                {
                 condition body
                } ifelse
        
Group like operations together.  For example,
        
        currentpoint 5 add exch 25 sub exch moveto (hello) show
        
        gets treated as
        
        currentpoint 5 add exch 
                     25 sub exch
                     moveto (hello) show                                        
 
Style 2.        Space efficient.
                The style primarily used in the GREEN book.  Close to the
                Indian Hill 'C' standard.
                
/procedurename { %def
        body
} def
        
        variable 0 eq { %ifelse
                 condition body 
        }{
                 condition body
        } ifelse
 
Don Hopkins notes that stack comments are extremely helpful.  Here is an
example.
 
 
%
% x y x' y' => x y w h
%
        /point2rect
                {
                 3 index 2 index min                % x y x' y' x
                 3 index 2 index min                % x y x' y' x y
                 5 index 4 index sub abs         % x y x' y' x y w
                 5 index 4 index sub abs         % x y x' y' x y w h
                 8 -4 roll pop pop pop pop        % x y w h
                } bind def
%
% x y w h => x y x' y'
%                
/rec2points 
        {
         2 index add                        % x y w (h+y)
         exch 3 index add exch                % x y (w+x) (h+y)
        }bind def
 
In Dons original form        
        
        /rec2points {% x y w h => x y x' y'
                2 index add                        % x y w (h+y)
                exch 3 index add exch                % x y (w+x) (h+y)
        }bind def
        
        /pop4        {% a b c d =>-
                pop pop pop pop
        } bind def                        
 
 
In this commenting style, the - means empty stack.  The top element of
the stack is on the right.  The => should be read  "yields"
 
Pick a style and be consistent.  Style 1 is probably the easiest and most
widely understood style.
 
A final note:
 
I have been maintaining a running archive of the PostScript group since
Jan 24, 1990.  
 
Currently it is up to 3 MS-DOS disks.  The only way it is currently
available is on MS-DOS 360K disks, in archived form.
 
It along with Crispins interpreter can be obtained as follows:
 
Email me a note, with name and address.  I'll mail you back a note telling
you how many disks the archive is up to.  Send me that many disks +1, along
with a self addressed disk mailer, with sufficient postage. Generally, 2 disks
require about .65 postage.  If in doubt, weigh it.  I'll copy the archives
to disk, and send them out via return mail.  The interpreter takes 1 disk.
 
Cheers
Woody
 
p.s. Sorry for the length.  If I tried to answer more questions this
would get real long.

glenn@heaven.woodside.ca.us (Glenn Reid) (03/06/90)

In article <18096@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
>This posting was developed to answer routine questions. If your question
>falls under one of the listed questions below, you likely will find the 
>answer here.  Please read the post before posting the question.  This has
>2 benefits.  The first is that your question gets answered faster.  The 
>second one is that it reduces traffic on the group.
> 
>NOTE: THIS IS A LONG FILE!  There are a lot of questions and information.

It is my humble opinion that this posting is not what we need.  It is far
too long, answers a strange bunch of questions, and the answers seem to
me to be extremely opinionated.  I don't believe that it will reduce traffic
on the group, and I, for one, don't like the idea of an automatic posting.
I am also not convinced that people's questions will be answered faster,
on the average, since the intersection between precisely these answers and
the average question seems likely to be very small.

A far better way to handle "routine" questions might be to have a friendly
agreement among the readership about who should answer questions, and
have only one person post a response.  That way you get an occasional
short question and a (hopefully) concise answer, which is the best way
to minimize the bandwidth.  Posting a monolothic message every so often
in the off chance that somebody might be wondering and in the even further
off chance that you have answered exactly the right question seems very
questionable to me.  In particular, I could see this generating MORE
discussion rather than less, as people posted follow-up questions and
other people started chirping in.

Also, why does Don Lancaster's phone number appear in the answer to all
of the questions?

So, to summarize, I object to anybody posting regular answers to imagined
questions, and if I am outvoted, then I strongly object to the long-winded
answers, and if I am outvoted again, then I'll just add it to my kill file
and suffer as little as I can.

I also think that, historically, people have done a very nice and concise
job of answering each other's questions, and that there is no particular
reason to "fix" this process.  Adobe answers most of the "technical"
questions, and happy (or unhappy) customers answer the product questions.

I got only four votes for my other idea of splitting off another group for
"PostScript the product", but all of them were "yes" votes.  Not nearly
enough to do anything about it, unfortunately.

Glenn

P.S.  Do any of you long-time netters out there have any statistics from
other newsgroups as to whether or not this technique works?  It can't be
the first time it's been tried.

zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) (03/07/90)

Personally, I think a frequently asked questions posting is a good
idea. But if it's going to be this one, it's going to need a lot more
than a few drafts. I started to write this as a brief reply, with the few
form-based comments I had on the first few answers (for instance, it
needs to be formatted to set off questions from answers; "high" needs
to be spelled "high" everywhere, and not "hi"; there's no reason to
say "the RED book" instead of "the Red Book"). Unfortunately, the
further I got, the less happy I was.

 I'm willing to write off as unneccessary quibbling my feeling that
the text is choppy. I'm not willing to write off referring to
Ultrascript PC and NeWS without mentioning what they are and what
machines they run on, or the gratuitous Adobe-bashing in that answer.
Nor am I willing to write off an answer to the question "What is EPS?"
that never actually answers the stated question! Or an answer to the
speed question which in successive paragraphs suggests one character
command abbreviations done as "\s {show} def" and then suggests using
"bind def" instead of "def".

  Writing for people who don't know the topic you're writing on is
tricky. You have to be correct, precise, and extremely explanatory.
This document needs *much* more work and thought put into it. While
Woody has provided the technical content, I don't think he has the
skills required to write it up well. I really would like to avoid
inserting myself into the middle of *any* argument in this newsgroup;
on the other hand, I'm a compulsive fixer of bad writing. If I rewrite
this sucker from scratch, am I going to find myself in the middle of a
flame war, or will it actually be useful?

	Elizabeth

zben@umd5.umd.edu (Ben Cranston) (03/07/90)

In article <151@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes:

> It is my humble opinion that this posting is not what we need.  It is far
> too long, answers a strange bunch of questions, and the answers seem to
> me to be extremely opinionated.

I do have an apparent conflict of interest since an ASCII printer I wrote
appears in the (current) automatic posting.  IMHO the automatic posting would
be 1000% better if it were organized more like the "Mac one-liners" posting
in the comp.sys.mac.programmers group.  Things like:

The "show" primitive cannot be made to do superscripting or subscripting.
Serial input to Apple LaserWriter converts runs of <CR>/<LF> into single <LF>.
Public-domain partial implementations (like GNU GhostScript) exist.
The key for eexec is d971 ce6d 58bf.
The key for internaldict is 1183615869.
To get full image area rectangle do clippath then get rectangle.

Well anyway you get the drift.
-- 

"It's all about Power, it's all about Control
 All the rest is lies for the credulous"
-- Man-in-the-street interview in Romania one week after Ceaucescu execution.

nelson@sun.soe.clarkson.edu (Russ Nelson) (03/07/90)

Pardones moi if this is too obvious, but shouldn't this be *in* postscript
as well as *about* postscript?
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems

glenn@heaven.woodside.ca.us (Glenn Reid) (03/07/90)

In article <30250@sparkyfs.istc.sri.com> zwicky@stegosaur.itstd.sri.com.UUCP (Elizabeth Zwicky) writes:

>on the other hand, I'm a compulsive fixer of bad writing. If I rewrite
>this sucker from scratch, am I going to find myself in the middle of a
>flame war, or will it actually be useful?

I'll support you!  I'll even help a little bit, time permitting.

I have two suggestions, if we go with the routine posting:

	1.  It be posted no more often than once a month.
	2.  The answers to ALL questions be:
		a) one line long, or
		b) pointers to "real" information

The key to this is going to be to keep it short, concise, short, accurate,
short, helpful, non-partisan, and short.  If anything smells of controversy,
then the question/answer simply should not be included in the list.  For
example, having 60 lines about indentation style is a bad idea.  Nobody
has actually asked that question, anyway; it started when somebody flamed
somebody else's style, which there's no preventing.

Just my opinions, of course.

Glenn

keil@apollo.HP.COM (Mark Keil) (03/07/90)

In article <151@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes:

> P.S.  Do any of you long-time netters out there have any statistics from
> other newsgroups as to whether or not this technique works?  It can't be
> the first time it's been tried.

I don't have statistics, but I do have observations from comp.graphics weekly posting.

After a delay of several months, comp.graphics now has some articles that start
with the comment that a person has read the monthly posting, and that their
question wasn't answered, or not answered as completely as they would like.
Then they launch into their question. Usually they are right that their question
wasn't answered. And sometimes they ask questions that do seem to have been answered
in the weekly posting.

And, there are the one shot question askers, that don't even (appear to) know
that there is a weekly posting that will answer their question. My suspicion is that
they come up with a question, ask themselves what newsgroup could answer it, and then
post the question to that group. Maybe without even reading up on the group to get the tenor
of the discussions.  I think we've even seen some of those here.

There are a lot of different access patterns to newsgroups. The gamut runs from the
regulars to the one shot lookers & askers. The only way to control The one shot askers,
is to go to moderation, or a digest form. A LOT of work for someone...

Unfortunately, everybody doesn't have access to ftp, and many aren't patient enough
to use uucp reachable archives. Otherwise we could refer newcommers to these.

It has occured to me that another option would be to keep track of who posts,
and auto-mail a frequently asked question file to newcomers, and those who havn't
posted in the last N months. They could also be sent a file of the last n months
postings, or told how to get them (assuming that someone sets up an archiver & server).

-Mark

 Mark Keil               Apollo Computer,  Chelmsford MA 01824
 +1 508-256-6600 x2495   keil@apollo.com  /  {decvax,mit-erl,yale}!apollo!keil

tinkelman@ccavax.camb.com (03/08/90)

In article <152@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn 
Reid) writes:
> I have two suggestions, if we go with the routine posting:
> 
> 	1.  It be posted no more often than once a month.
> 	2.  The answers to ALL questions be:
> 		a) one line long, or
> 		b) pointers to "real" information
> 
> The key to this is going to be to keep it short, concise, short, accurate,
> short, helpful, non-partisan, and short.  

I'll second that.  (Or, maybe it's ``I'll third that.'')  I think it's
important that we state the goal and keep it in mind.  My understanding of
the goal is to reduce the number of repetitive postings of common questions.

A posting like the one Glenn suggests will be enough for people with both a
question and enough net-experience (or common sense and courtesy) to look
around for the answer before posting.  I'm afraid that people lacking those
qualities will post no matter what sort of ``routine posting'' we have.
-- 
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
bob@ccavax.camb.com  or ...!uunet!ccavax!bob      

woody@chinacat.Lonestar.ORG (Woodrow Baker) (03/08/90)

In article <6220@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes:
....stuf deleted to satisfy innews...d
> The key for eexec is d971 ce6d 58bf.
> The key for internaldict is 1183615869.

Yep.  That is not a bad Idea.  I'll see what I can do about some of them.
I roughly modeled this off an automatic posting in another newsgroup.
Cheers
Woody


> -- 
> 
> "It's all about Power, it's all about Control

woody@chinacat.Lonestar.ORG (Woodrow Baker) (03/08/90)

In article <NELSON.90Mar6165926@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
> Pardones moi if this is too obvious, but shouldn't this be *in* postscript
> as well as *about* postscript?

Absolutely NOT.  There are people who need to read it that don't have printers
handy, and besides that, you wouldn't want all the extra preamble tacked on it
nor would you want extensive lines of xx yy moveto (sadfasdf) show
on your screen, and I would not want to write it that way.  Documentation
should be documentation, not programs to print documentation.

Cheers
Woody


> --
> --russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
> Violence never solves problems, it just changes them into more subtle problems

woody@chinacat.Lonestar.ORG (Woodrow Baker) (03/08/90)

In article <490b58d0.20b6d@apollo.HP.COM>, keil@apollo.HP.COM (Mark Keil) writes:
> 
> question wasn't answered, or not answered as completely as they would like.
> Then they launch into their question. Usually they are right that their question
> And, there are the one shot question askers, that don't even (appear to) know
> ther
> 
> 
> Unfortunately, everybody doesn't have access to ftp, and many aren't patient enough
> to use uucp reachable archives. Otherwise we could refer newcommers to these.
> 
> It has occured to me that another option would be to keep track of who posts,
> and auto-mail a frequently asked question file to newcomers, and those who havn't

Basically, I had intended to mail it weekly or perhaps monthly, but certainly
when a new reader pops up. It is around to try to answer a packet of questions.
Most of the questions were picked due to someone asking them more than 1 time.
I am still not sure of the frequency, but if a newcomer asks a question in it,
it will be posted.  That will perhaps head off a list of further questions
and comments.

Cheers
Woody


>