geertj@nlgvax.UUCP (Geert Jan de Groot) (02/09/89)
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). Such neat setups may work with a printer directly connected to the PC (but need special drivers - horror stories on that?), but if one connects a printer via a network (I use PC-NFS, allows sharing of the not-so-cheap printer), those methods fail badly. 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. - Not use 8-bit characters. Not every connection is 8-bit; why should one need 8-bit characters anyway? - 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. - End with 'showpage'. What's the use of sending data without giving the command to print it? - 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). - Not leave resident code behind after the job is done. Because I find most PostScript support available on update disks and add-on packs and new versions, I think most software houses are just beginning using PostScript. With this article I hope to start a discussion on guidelines how things can be done, something which can be easily added while the PostScript support is still under development. Also, what packages already use clean PostScript these days? I tried WordPerfect, Lotus 123, ORCAD, ChiWrite, but they all gave more or less trouble with the points mentioned above. How about other packages? Thanks, Geert Jan _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. Geert Jan de Groot, Email: geertj@nlgvax.pcg.philips.nl Philips Research Laboratories, ..!mcvax!nlgvax!geertj Project Centre Geldrop, Packet: PE1HZG @ PI8ZAA Building XR, Room 15, Willem Alexanderlaan 7B, "MS-DOS is just a bootstrap" - me 5664 AN Geldrop, The Netherlands. phone: +31 40 892204 [Standard disclaimers apply]
hst@mh_co2.mh.nl (Klaas Hemstra) (02/10/89)
From article <204@nlgvax.UUCP>, by geertj@nlgvax.UUCP (Geert Jan de Groot): > 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). .. Stuff deleted > - 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. I do not agree, this should work ok. The purpose of a network is to share printers / discs as if they were yours, so if you can use a printer that is directly attached to your computer why can't you use that same printer through the network ? I would consider that a bad network. > > - Not use 8-bit characters. Not every connection is 8-bit; why should one > need 8-bit characters anyway? Also not agreed. This sounds fine when you talk about a postscript printer but may indeed be nessecary with other printers. Ever tried to use a Epson printer to print graphic images when there is only an 7 bits connection to it ? > - 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. > > - End with 'showpage'. What's the use of sending data without giving > the command to print it? > ..... Stuff deleted Finally: I realise that maybe this followup is a little focussed on other printers, but that s the point I try to make. I think its a mistake of the network when certain special codes are not passed on correctly. Lately I had a problem with an Epson and an HP Laserjet printer, both attached to a network. They would not print graphics correctly. As it turned out the network expanded tabs to spaces. Fortunately this "feature" could be turned off. Thats why I find that you should not blaim PostScript for things that are really the networks fault. Klaas Hemstra (hst@mh.nl) | / / ,~~~ ~~/~~ uucp: ..{uunet!}hp4nl!mh.nl!hst | /--/ `-, / ___ |_/ |__| Multihouse N.V., Gouda, the Netherlands | / / ___/ / --- | \ | |
nelson@sun.soe.clarkson.edu (Russ Nelson) (02/11/89)
Painter's Apprentice (available from grape.ecs.clarkson.edu as below and
from Compu$erve's IBMAPP Graphics area (pa.arc) follows exactly the guidelines
that you outline. Painter's Apprentice is a bitmap editor in the genre of
MacPaint, Dr. Halo, and PC-Paintbrush.
Grape:
The semi-official c.b.i.p archives are on grape.ecs.clarkson.edu which
is a Zenith Z-248 running a modified version of KA9Q's TCP/IP NET that
allows you to shell out to DOS while still processing packets. After
shelling to DOS, we run an Opus BBS. The particulars:
FTP: grape.ecs.clarkson.edu [128.153.13.196], user anonymous, password guest.
Look in 00readme for timely information.
Look in /d/files/general/cuhug.lst for a listing of files.
Look in /e/files/binaries/*.* for c.b.i.p postings.
Look in /c/files/gif for .GIF images.
Look in /d/files/graphics/pa.arc for Painter's Apprentice
Look in /e/files/freemacs/* for Freemacs
Opus: 260/360 in the Nodelist. (315)268-6667, 8N1, 1200/2400 Baud, 24 hours.
Look in file area 12 for Painter's Apprentice
Look in file area 25 for Freemacs
Look in file area 26 for c.b.i.p postings.
Look in file area 27 for .GIF images.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lamageof@apolling (Geof Cooper) (02/14/89)
Why don't you move your discussion of PostScript to comp.lang.postscript? - Geof
greid@adobe.com (Glenn Reid) (02/16/89)
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