glenn@heaven.woodside.ca.us (Glenn Reid) (06/27/90)
In article <9006270115.AA21371@terra.oscs.montana.edu> uphwk@TERRA.OSCS.MONTANA.EDU (Bill Kinnersley) writes: >Ulp, I don't want to get in between Woody and Glenn on this, but actually >guys, PostScript is an 8 bit language, not 7. True. It supports 8 bits, but it is possible to express all programs in 7 bits, which is partly why I called it a 7-bit language. >In fact, Aldus PageMaker produces PostScript files which contain 8-bit >non-ASCII characters. As far as I can tell, this is perfectly legal. Perfectly legal often means that "it prints" on the one printer somebody tested it on.... It's perfectly legal, but tends to cause all manner of problems when the file is moved from the Macintosh environment. This is mostly because the world at large can't be assumed 8-bit clean. Serial ports have parity bits set; modems, software, electronic mail transport, bad cables--there are lots of places to lose the 8th bit. For good portability, you have to stick with 7 bits. But the point, as I remember it, was that it's not the serial port that is limited to 7 bits. In fact, the 8th bit has nothing to do with things like control-C, control-D, etc. It's the standard serial line PROTOCOL that treats these characters as special. And although, as Woody points out, it is possible to circumvent some of these with things like DTR/DSR, it's not guaranteed, and not always possible, depending on lots of things. The original discussion had to do with emulating other printers and how come you couldn't pass arbitrary binary data down through the serial port, which does present a bit of a problem. We've been haggling over just where the problem lies, but the more I think about it, the less I think I want to use my LaserWriter II NTX as a LaserJet printer anyway. There are over 4000 applications that product PostScript, and I don't own any computers that run software that doesn't produce PostScript. Or something like that. But you're quite right, PostScript can be an 8-bit language. I'm sorry to belabor all of this, but for some reason I always jump in when somebody says something like "Adobe in their *infinite* wisdom...." PostScript isn't everything for everybody, but it's one of the best designed pieces of system software that I've ever encountered. I'd rather use PostScript for those things at which it is wonderful than to complain that it doesn't do a good enough job emulating a brain-dead printer. But I guess things only get better when enough people complain about them :-) Glenn -- % Glenn Reid PostScript consultant % glenn@heaven.woodside.ca.us Free Estimates % ..{adobe,next}!heaven!glenn Unparalleled Quality
henry@utzoo.uucp (Henry Spencer) (06/28/90)
In article <1363@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >... My point is and >has been that Adobe should have made the language fully 8 bit transparent... The language *is* 8 bit transparent, or approximately so; the problem is the serial transmission protocol. What is wanted, rather than inventing half-assed botches with modem-control lines and the like, is to have the printer speak a *real* protocol -- say TCP/IP -- over the serial line. (Yes, Virginia, you can use TCP/IP over serial lines, and many people do.) Then all the problems -- flow control, error detection, end-of-job marking, status queries and commands while a job is executing, etc. -- are solved in one fell swoop. Best of all, there is no fiddling with modes, and no chance of leaving the printer in the wrong mode. -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John Osterhout | henry@zoo.toronto.edu utzoo!henry
shore@adobe.com (Andrew Shore) (06/30/90)
In article <1990Jun27.201333.10418@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <1363@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >>... My point is and >>has been that Adobe should have made the language fully 8 bit transparent... > >The language *is* 8 bit transparent, or approximately so; the problem is >the serial transmission protocol. What is wanted, rather than inventing >half-assed botches with modem-control lines and the like, is to have the >printer speak a *real* protocol -- say TCP/IP -- over the serial line. A bit of history here. Would you believe that very early on in PostScript development (early 1984) we considered having Kermit be a communications mode on the original LaserWriter. For a variety of reasons this was scrapped, but I thought you might find the idea cute. It would have allowed 8 bit transparent data, however. Of course, then people would have complained about the speed :-) Serial IP is another good idea. Whose flavor of SLIP do you like? Or should we have waited for PPP? Or invented our own? --Andy Shore shore@adobe.com
amanda@mermaid.intercon.com (Amanda Walker) (06/30/90)
In article <3439@adobe.UUCP>, shore@adobe.com (Andrew Shore) writes: > Serial IP is another good idea. Whose flavor of SLIP do you like? > Or should we have waited for PPP? Or invented our own? Personally, I always thought that Apple LocalTalk was an excellent choice. The biggest problem with it is that nothing much speaks it except Macintoshen and PCs, but it does all of the things that people seem to want: error checking, out-of-band job control/flow control/status reporting, 8-bit transparency, and speed. For a minimal-hardware printer like a LW, it's nice. Now, what I think would be ideal for higher-end stuff like Linos or Varitypers would be to use TCP/IP over Ethernet. Unfortunately, though, async serial is the lowest common denominator. As soon as you layer a protocol on top of it, though, both sides have to speak it, which would defeat Woody and others who want to convince the host that it's talking to a Brand Y printer. -- Amanda Walker InterCon Systems Corporation --
phillips@tegra.COM (Steve Phillips) (07/04/90)
In article <268C0233.50F0@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Personally, I always thought that Apple LocalTalk was an excellent choice. ... >For a minimal-hardware printer like a LW, it's nice. Now, what I think >would be ideal for higher-end stuff like Linos or Varitypers would be >to use TCP/IP over Ethernet. Warning - product plug ahead... :^) Actually, the Varityper 5000 series already does support ethernet. Our newest software release supports the BSD network printing protocol, so you can print to PostScript devices using the lpr command from your UNIX workstation. - Steve -- ============================================================================ Steve Phillips Tegra-Varityper, Inc. tegra!phillips@uunet.com Billerica, MA ============================================================================
henry@zoo.toronto.edu (Henry Spencer) (07/04/90)
In article <3439@adobe.UUCP> shore@adobe.COM (Andrew Shore) writes: >>... What is wanted, rather than inventing >>half-assed botches with modem-control lines and the like, is to have the >>printer speak a *real* protocol -- say TCP/IP -- over the serial line. > >A bit of history here. Would you believe that very early on in PostScript >development (early 1984) we considered having Kermit be a communications >mode on the original LaserWriter... Nah, I don't believe it. :-) :-) :-) A plausible notion, although as you note, it does have performance problems. >Serial IP is another good idea. Whose flavor of SLIP do you like? >Or should we have waited for PPP? Or invented our own? Last I heard there was only one flavor of SLIP in wide use, although I suppose there's nothing that deranged people won't mutate... Having *something*, preferably standard SLIP, would have been better than having nothing. (Of course, it does get you into the swamp of assigning IP addresses and such, although there is an EEPROM in the LW at least.) Yes, I'm aware that insignificant trivia :-) like delivery dates do sometimes limit what can be done... Sigh. -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John K. Ousterhout | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (07/04/90)
In article <268C0233.50F0@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Personally, I always thought that Apple LocalTalk was an excellent choice. >The biggest problem with it is that nothing much speaks it except Macintoshen >and PCs... The biggest problem with it is that it's not available over the RS232 port. People would have written software to speak the printer protocol, whatever it was, but having to add funny new hardware just to talk to the printer was a much bigger obstacle. >Unfortunately, though, async serial is the lowest common denominator. As >soon as you layer a protocol on top of it, though, both sides have to speak >it, which would defeat Woody and others who want to convince the host that >it's talking to a Brand Y printer. There's nothing wrong with having a dumb-serial protocol available for people with Brand-Y constraints. That does not preclude having something better too. -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John K. Ousterhout | henry@zoo.toronto.edu utzoo!henry
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (07/04/90)
In article <1990Jul3.172953.6474@zoo.toronto.edu> henry@zoo.toronto.edu (Henry >>development (early 1984) we considered having Kermit be a communications >>mode on the original LaserWriter... > >A plausible notion, although as you note, it does have performance problems. > Well actually, you must admit that althought kernmit may not be the fastest transfer in the west, it is pretty fast, and is one of a very very few packages (software) that is worth at least twice what you pay for it. 8-) al
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (07/04/90)
In article <1990Jul3.173300.6547@zoo.toronto.edu> henry@zoo.toronto.edu (Henry >>The biggest problem with it is that nothing much speaks it except Macintoshen >>and PCs... >The biggest problem with it is that it's not available over the RS232 port. >People would have written software to speak the printer protocol, whatever >it was, but having to add funny new hardware just to talk to the printer >was a much bigger obstacle. Actually, I see it slightly differently. The problem is more like 3 tiered. First, supporting apple/local/talk requires fairly highly timed detailed protocools. If it is supported by the/a main processor, the overhead is signifigant. If it is to be downloaded to a xxx/talk onlpy processor, that adds signifigant complexity to a otherwise almost trivial hardware serial (basically) interface. In most worlds, this makes for terribly expensive boards. Apple drove the market price for the pc card dowbn to help support the protocool. Lastly, as a printer/sharing/LAN it has severe/major/... limitations. For a few users or a small network, it is great. Fast, easy, simple, cheap... For a larger network with a light printing load, else a mixed market basket of printing, it also is quite good. Fast-enough, easy, simple-enough, cheap. HOWEVER, for a large netowrk (say 30 or more) users and multiple printers, say 3 or more, it sucks the big wazolla. It becomes almost a agony to use, and people line up by the printers waiting for output... al
pgd@bbt.se (P.Garbha) (07/04/90)
In article <1095@io.tegra.COM> phillips@io.UUCP (Steve Phillips) writes: > >Actually, the Varityper 5000 series already does support ethernet. The Linotronic 300 also have an optional ethernet interface.
philip@pescadero.Stanford.EDU (Philip Machanick) (07/05/90)
In article <3803@rodan.acs.syr.edu>, amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: > In article <1990Jul3.173300.6547@zoo.toronto.edu> henry@zoo.toronto.edu (Henry > >>The biggest problem with it is that nothing much speaks it except Macintoshen > >>and PCs... > >The biggest problem with it is that it's not available over the RS232 port. > >People would have written software to speak the printer protocol, whatever > >it was, but having to add funny new hardware just to talk to the printer > >was a much bigger obstacle. Not on the Mac. You didn't even need a network connector for a single Mac to talk to a LaserWriter - I've seen this done with a straight through cable. My guess is almost all PS printers come with AppleTalk because it's no big incremental cost after Adobe designed it once for Apple. > Actually, I see it slightly differently. [stuff about why localtalk is expensive] > ... Apple drove the market price for the pc card down to > help support the protocool. Hmmm. As I recall, Apple invented the protocol at a time when it was _not_ company policy to cohabit with other people's equipment. AppleTalk was integrated into Macs, and was almost no extra cost (one cheap connector per node) for Mac users. > Lastly, as a printer/sharing/LAN it has > severe/major/... limitations. For a few users or a small network, it > is great. Fast, easy, simple, cheap... For a larger network with a > light printing load, else a mixed market basket of printing, it also is > quite good. Fast-enough, easy, simple-enough, cheap. HOWEVER, for a > large netowrk (say 30 or more) users and multiple printers, say 3 or more, > it sucks the big wazolla. No surprise here. These were the intended design limits. The original LaserWriter was also not fast enough for a large group, and the Mac was intended to be networked in small groups. Has the fact that postScript has become so successful made some people forget that there was a time when only Apple was pushing it in a big way? Hence Apple design decisions embedded in subsequent Adobe implementations. Philip Machanick philip@pescadero.stanford.edu
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (07/05/90)
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >To answer this, lets first deal with XON/XOFF. Under DSR/DTR mode (which >you can set along with 8 bits), you don't need XON/XOFF. Under DSR/DTR >mode XON/XOFF should be allowed through. Woody, you should check out the real world before making assumptions about peoples communications environments. In our building, we have about 300 serial lines. They connect printers and terminals to the computer room. This involves running a LOT of cable. Have you checked the price of eight conductor cable versus that of three or four conductor cable? If you had, you would see that the cost of our wiring plant would have doubled had we run eight wire cable, just to provide hardware handshaking for 10 or so postscript printers out of 300 devices. Of course, you could run eight wire cable to the printers only. The trouble is that printers move, but cabling doesn't. The costs of moving a cable, or running in a new one are prohibitive. Try keeping your physical plant documentation up to date when everything is the same, except for this one over here ... >The second part of this, such >as terminating a job, is what the hardware control lines are for. The >break key (Not necessarily on a PC) sends a signal (I think it locks >the line in either space or mark for 500 ms or so) that would serve >nicely to stop the printer, or allow you to regain control. Again, you should investigate the real world. Nearly all our serial lines pass through a PACX on their travels between the mainframes and the peripherals. Sending a break through the PACX suspends your current session and returns you to the PACX command processor. Using break like this is fairly common in communication switching equipment. Needless to say, this type of behaviour is going to confuse your spooling software to no end ... >What >I would do, is to make the input routines smartenough to check for >an ESCAPED sequence to force end of program, and queries. An example >might be based on the OCTAL escape sequence hander \ooo, but would >be \0xHH. Using '\' as an escape character isn't much different than using ^D. >The input routine would translate \0xHH into an internal >byte that would then terminate the job, or return status etc. the >\ooo would be translated directly into binary, rather than passed >thorough as "\ooo". >I personaly favor >using hardware control lines to handle handshaking, and break control. So do I, but only where it's *practical* ! >look at the result for the switch handling procedure. My point is and >has been that Adobe should have made the language fully 8 bit transparent, >or at lease provided an operator to allow this capablilty, and DOCUMENTED >it. As Henry Spencer mentioned, the proper way to allow for FULL eight bit transparency is to implement it inside a documented protocol. The reason you can ship eight bits inside of Appletalk is that you are using the facilities of that protocol to get the bytes through. I don't think Appletalk was the best protocol to use, but that's a whole new barrel of snakes. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Practice Safe Government Use Kingdoms
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (07/06/90)
amanda@mermaid.intercon.com (Amanda Walker) writes: >Now, what I think >would be ideal for higher-end stuff like Linos or Varitypers would be >to use TCP/IP over Ethernet. A great transport, but it still doesn't address the problem of what protocol to run over it. Since I don't want Joe_Randomn_User dumping jobs to the Linotron, you're going to need something that implements reasonable amounts of security. Hooks for job accounting would also be looked upon with favour. If you invent a new protocol, no existing systems will speak it. Therefore you are pretty well stuck distributing source for the printer driver. Given wide variety of OSs you'll have to support, the code will have to be pretty damned generic. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Practice Safe Government Use Kingdoms
beck@cs.Princeton.EDU (Stephen Beck) (07/19/90)
You might consider using the TCP/IP protocol devised by DEC for use with their lps40 hanging off the net. Stephen Beck