Xref: utzoo comp.binaries.ibm.pc.d:1865 comp.lang.postscript:1626
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!adobe!greid
From: greid@adobe.com (Glenn Reid)
Newsgroups: comp.binaries.ibm.pc.d,comp.lang.postscript
Subject: Re: DOS programs and PostScript
Message-ID: <488@adobe.UUCP>
Date: 16 Feb 89 01:25:48 GMT
References: <204@nlgvax.UUCP>
Sender: news@adobe.COM
Reply-To: greid@adobe.COM (Glenn Reid)
Followup-To: comp.binaries.ibm.pc.d
Organization: Adobe Systems Incorporated, Mountain View
Lines: 71

I think that this is an excellent topic for discussion.  I see it as
a major problem with the use of PostScript in the PC environment.

In article <204@nlgvax.UUCP> geertj@nlgvax.UUCP (Geert Jan de Groot) writes:
>Hi,
>
>I would like to start a discussion on use of the PostScript language by
>DOS programs. While PostScript has the ability to build a real portable
>printer interface, most programs use some fancy method which may give
>trouble connecting a printer (for instance, laserwriter plus).

>What should portable postscript code look like? In my opinion, it should:
>
> - Not use control characters, only CR, LF. Especially, no control-C,
>   control-D, control-U and the like. These control-characters are likely
>   to screw up a printer spooler, like SUNOS.

In general, this is true.  However, control-D is necessary to end a job
if it is being sent on a serial line or a parallel port to a printer.
The main objective is to treat these as part of the TRANSMISSION of the
file, and not as part of the file itself.

> - Not use 8-bit characters. Not every connection is 8-bit; why should one
>   need 8-bit characters anyway?

Yes, I agree with this.  The PostScript language is carefully defined
to be fully expressible in 7-bit ASCII for portability.

> - Start with '%!'. This will trigger newer software that a PostScript
>   file follows. This allows mixing of PostScript with other types of 
>   files. Because % starts a comment, there is no reason to omit this
>   lead-in.

This is a good idea, too.

> - End with 'showpage'. What's the use of sending data without giving
>   the command to print it?

This is not a good convention, for many reasons.  First of all, things
like downloadable fonts will not print any pages.  Second of all, the
"showpage" operation may be contained in a procedure body, and will
not necessarily appear at the end of the file.

> - Not depend on sending some init data to the printer when the program
>   starts, but send all data (including PostScript lead-ins et all)
>   one after another for each job. Sending init only at the start of
>   a program gives trouble with spooled jobs (i.e. other data being 
>   printed between the init code and the output of a program).

Yes.  The "exitserver" operator is not really portable, and dependence on
it is not a good idea.  In particular, previewers and Display PostScript
interpreters may or may not support the notion of a server loop.

> - Not leave resident code behind after the job is done.

A good idea.

For more information on portability, please retrieve the Encapsulated
PostScript File specification from our server, by sending a mail
message to "ps-file-server@adobe.com" containing the line:

send Documents EPSF.ps

Thanks for sending this message.  Adobe is very interested in the
portability of documents (especially in the PC environment) and we'll
do what we can to encourage it.

--
Glenn Reid
Adobe Systems
Developer Tools & Strategies