laser-lovers@uw-beaver (10/09/85)
From: Perry Smith <pedz%ct.csnet@csnet-relay.arpa> First, there seems to be many questions on the net about conversion programs from text processor x to printer y (TeX to Imagen, ditroff to HP laserjet, ...) I know that TUG Boat keeps track of the TeX dvi post-processor programs but someone (I thought) should keep track of all of them (or at least make some attempt to do so). So I will volunteer my services for this activity if all of you bright people out there will send me whatever information you have about these types of programs. Make sure to explain if they are freeware or not (I plan to keep track of both) and a way to get the software. The two types of post-processors that I am currently thinking about are TeX dvi to some printer (or other language) and ditroff dvi to some printer. I assume that Unilogic keeps track of the scribe to printer description files so that probably need not be sent to me. Now for my question: Those people that have a newer Imagen hooked serially to a computer (vax or whatever), do you use the sequence packet protocal or the byte stream protocal? The reason I ask is I notice that the 8/300 can print faster than the vax can send it data using the sequence packet protocal. So I was wondering with the faster printers, how do you get the infomation to the printer fast enough to take advantage of the speed. I realize that you could use ethernet but assume that is not the usual practice. What is the advantage of either protocal? Perry Smith pedz@ct (csnet) pedz%ct@csnet-relay (arpa) convex!ctvax!pedz (uucp)
laser-lovers@uw-beaver (10/14/85)
From: Robert Morris <ram%umass-boston.csnet@csnet-relay.arpa> At Interleaf we support both protocols (from different hosts). The spp is more robust and also capabable of reporting more error conditions. The robustness may not be an issue on short cables. The byte stream protocol seems to be more useful than the spp in a VMS environment, because VMS has such an inflexible spooling system (for example, it is a little tough to get it to send things transparently and not add special control characters to help the printer along....). On Sun systems we support the spp and do a fair bit of printer condition reporting. btw, old versions of Imagen's spp made it difficult to force a page out of the printer just because it was fully sent to the host (namely, if the page boundary did not occur on a packet boundary nor on the job boundary, their software did not send an incomplete packet (other than at the job end)). I don't know if later software fixed this, but one can envision circumstances where one might want the host to pause in the middle of the job and await operator intervention at the printer, some schemes for which require sending partial impress jobs and continuing later under software control. For example, if you want to do double sided printing on an 8/300 and provide for timeouts (i.e. the printer should not require intervention to continue if no one turns the paper withing N minutes), you are lead to such a solution. So, if you modified Imagen software to implement this you may not get quite enough use of the spp without a little thought. I believe there is a similar problem with ethernet protocols, and it may be hopeless with the byte stream protocol. A nice hardware solution(?) would be if printer vendors could insure that there is a way for an operator to do something physical at the printer which could be detected by the host. Then an operator who successfully changed paper, etc., could notify the host software to continue. This seems simpler than the elaborate printer control mechanisms in Interpress. bob morris interleaf, inc. and UMASS/Boston