INITIAL SPECIFICATION OF THE MULTIPLE PRINT FACILITY

PROBLEM: It is desired to define an E-Press document and a document
issued by the ETAI as consisting of several files, and not simply 
one file. This need arises for the following reasons:

-  Need to print a few pages on a color printer, the rest of the pages
   on a black-and-white printer

-  Desire to be able to direct the cover pages (first and last) to a
   printer with heavy bond paper

-  Need to define a journal issue as a sequence of articles

-  For technical reasons in the word processing, need to develop the
   cover page separately from the content pages; postscript does not
   allow those parts to be concatenated

-  When preparing proceedings, need to let each article be a file of
   its own so that it can be printed separately, but also to print out
   the whole proceedings in one request, and to *define* the proceedings
   contents as a sequence of files

-  In the context of proceedings, one and the same paper shall both be
   printable as a part of the proceedings, and as an offprint. In the
   latter case, the produced document should contain some first and last
   pages (cover, copyright information, etc) which is not present in
   each of the articles of the full proceedings volume, but only at
   the beginning/end of the whole volume.


PROPOSED SOLUTION: 

1. Each constituent file is stored at its own URL. If it exists in
   several formats (ps, pdf, ...) then those also have individual URL:s.

   Typically, each lowest-level subdirectory contains several files
   all belonging to one article, for example the full text, the
   required copyright info page, etc. Printing out an article only
   requires using files within one subdirectory, but printing out a
   proceedings requires to get them from several subdirectories.

2. Every "document" from the external point of view is defined by a small
   configuration file whose name has the extension .dcd (document 
   contents definition). For the single article, normally there is a file 
        article.dcd
   specifying contents.

   The dcd file has the structure suggested by the following example:

      bw http://.../.../.../readme.txt
      hb http://.../.../.../cover.ps The cover
      bw http://.../.../.../body.ps The body of the article
      cp http://.../.../.../illustr1.ps Illustration 1
      cp http://.../.../.../illustr2.ps Illustration 2

   Of course, there is real contents instead of the ...
   In general, each line contains a printer code, a URL, and an optional
   explanatory text, separated by one blank space. The printer codes are:
   
      bw   send this to the black-and-white printer
      cp   send this to the color printer
      hb   send this to the heavy-bond (carton paper) printer

   where "this" is the file at the specified URL. The explanatory text
   is only used for error messages, e.g.
      Illustration 1 can't be printed - printer not available

3. Two software things are needed. One is a UNIX script which will print
   out things using such a recipe. The script shall depend on a number
   of environment variables, namely:
     -  the ordinary printer variable for directing bw output
     -  variables specifying which printer to send cp and hb to
     -  a variable containing the main part of a URL, up to the final name

   Let's say the script is called wp (web print). Invoking
      wp paper2
   will have the effect of concatenating the URL environment variable,
   "paper2" and ".dcd" and getting that file over the net (call to
   wwwget program). Then, it decodes the file it has received, and
   for each line it fetches the file and sends it to the printer in
   question.

   The argument to wp is allowed to contain / referring to further
   subdirectory levels. To obtain the latest issue of a particular
   newsjournal, the author may type
        wp etai/nj/rac/november
   and the right things happen (... look up ..../november.dcd and
   take it from there)
 
4. The other thing that's also needed is to allow .dcd files to be
   referred in HTML links. Thus, the Netscape browser must be told
   to recognize links to ---.dcd files, and to invoke the wp script
   in such cases. (It should ask the user to click an OK box *once*
   for the whole document, not once per constituent file, before it
   starts printing).

I assume that it's easiest to code wp in UNIX script language, but if
it turns out to be easier to do it in an ordinary programming language
that's fine as well.


OTHER:

We want this to be a service that anyone can use, worldwide,
so it should rely minimally on properties of the local system. 
Good instructions for the user is a must.

We set it up for UNIX first, but once it gets going we need it for
PC's as well.

It is intended that the first file  ("readme") is something which goes
to the bw printer and contains instructions for how to assemble the
document: what things are supposed to come out of which printer, and 
in which order to put them together. This is generated into the readme
file, so wp doesn't have to worry about it.


REALIZATION:

The implementation now works and is being tested. The script is
available in the present directory with the name wp.

For a simple example, try
   setenv BW_PRINTER "e1n"
   setenv CP_PRINTER "ec0"
   wp -u http://www.ida.liu.se/ext/etai/actions/nj/9709/ issue

which prints out according to the recipe
   
   http://www.ida.liu.se/ext/etai/actions/nj/9709/issue.dcd


(At present, only seems to send to default printer in some cases)