prc@erbe.se (Robert Claeson) (11/28/89)
I have a few questions regarding Adobe's PPD (Postscript Printer Description)
files.
1. If I change the password in the printer, how should I record it in
the PPD file? Adobe suggests me not to change any piece of the
information in the PPD file. Should this suggestion be followed
for the exitserver password also?
2. If I want to have a spooler (suppose I'm writing my own) make use
of the various emulations available in most Postscript printers,
such as HP Laserjet+, Diablo 630 and HP-GL, how should I add that
information to the PPD files? Is it even "legal" to extend the PPD
files in this way?
I hope that someone would be willing to respond to these questions.
--
Robert Claeson E-mail: rclaeson@erbe.se
ERBE DATA ABwoody@rpp386.cactus.org (Woodrow Baker) (11/29/89)
In article <1025@maxim.erbe.se>, prc@erbe.se (Robert Claeson) writes: > I have a few questions regarding Adobe's PPD (Postscript Printer Description) > files. > > 1. If I change the password in the printer, how should I record it in > the PPD file? Adobe suggests me not to change any piece of the > information in the PPD file. Should this suggestion be followed > for the exitserver password also? > > 2. If I want to have a spooler (suppose I'm writing my own) make use > of the various emulations available in most Postscript printers, > such as HP Laserjet+, Diablo 630 and HP-GL, how should I add that > information to the PPD files? Is it even "legal" to extend the PPD > files in this way? > > I hope that someone would be willing to respond to these questions. > > -- > Robert Claeson E-mail: rclaeson@erbe.se > ERBE DATA AB DON'T change the serverdict password. If for some reason you forget it, you will have to send the controller off to get it recovered. Secondly, may aplications depend on server password to be the default of 0 and will flat out fail. Thirdly, Adobe in thier infinite wisdom decided not to document the proceedure for accessing the emulatons from within postscript. Depending on the machine. Some machines have setsoftwareiomode and sethardwareiomode commands that allow this. Older machines don't. I have worked all that out for QMS-ps810's and The Laser Connection sells a piece of code called PSexecutive that does it nicely, based on the information that I sold them. Drop me a note as to which laser printer you have, and I'll see if I can help you. basically, if you use the laserprinter in interactive (rs-232) postscript mode you can do this: connect your favorite computer and communication program up to the laser using the db25 connection. type in executive <return< in lowercase (<return< means hit the return key. You should see the PS> prompt. then type in serverdict begin statusdict begin <return< /statusdict load {== ==} forall <return< you will get a dump of the internal statusdict entries. Capture this to disk. Do the same for /serverdict and /$printerdict. You can look at this. There is a proceedure called switch or something like that that handles the changing of emulation modes when the switch is flipped on the side. I think that you'll also find one that invokes the emulations: serverdict begin hplj <return< or hpgl <return< usually does it, but you need to look at your serverdict and statusdict dumps to see how your machine does it. simply copy it..... Cheers Woody
henry@utzoo.uucp (Henry Spencer) (12/01/89)
In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >DON'T change the serverdict password. If for some reason you forget it, >you will have to send the controller off to get it recovered. Secondly, >may aplications depend on server password to be the default of 0 and will >flat out fail. ... In a shared environment, this is a feature, not a bug. We *want* those applications to fail; we do not want them messing with persistent characteristics of the printer. They have no damn business doing so anyway. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
woody@rpp386.cactus.org (Woodrow Baker) (12/01/89)
In article <1989Nov30.171926.7946@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >DON'T change the serverdict password. If for some reason you forget it, > >you will have to send the controller off to get it recovered. Secondly, > >may aplications depend on server password to be the default of 0 and will > >flat out fail. ... > > In a shared environment, this is a feature, not a bug. We *want* those > applications to fail; we do not want them messing with persistent > characteristics of the printer. They have no damn business doing so anyway. > -- > Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology > started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu I have to disagree with you. Applications do have to do that. Messing with persistant paramenters is not the issue here. Any program that downloads a preamble and a resident portion has to exit to the server. Examples, Microsoft word, Pagemaker, Ps executive, my Epson emulator, Diablo emulator, All of Cassidy and Greenes fonts, and many others. The situation is that many of these things have to install utility routines to be used by more than one application. For example, you have a problem like the one that certain Dual bin QMS printers had. HPLASERJET emulation mode didn't recognize dual trays. You could not switch emulations etc.etc. The PS-executive handles these by downloading some printer patches that have to be persistant. The MS word driver then was altered to know about them. PS-exec assumes the password to be 0. The code is not held in a file. It is printed from within a program. It's not super easy to change. The second real problem, is that with most of the Apple printers, and nearly all of the other older printers if you forget the server password, you are out of luck. You have to remove the logic board, and send it in to Apple, or the manufacturer to get it corrected. this costs lots of time and cash....On certain printers like the QMS, the battery-backed (vs EPROM) chip is socketed, and can be removed. BUT, you still have to have someway to wipe the password out of the chip and Adobe, in thier "infinite wisdom" won't tell you where in the thing it is stored. Just wiping the entire contents out is not good either. You wipe the calibration data out, such as the compensation for the hardware margins, the pagecount, etc, etc. I never claimed that this was a bug, just a severe pain in the "btt" for people. Again, DON'T change the password, it could cost you far more than it is worth.. Cheers Woody.
amanda@mermaid.intercon.com (Amanda Walker) (12/02/89)
In article <17391@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > I have to disagree with you. Applications do have to do that. Messing with > persistant paramenters is not the issue here. Any program that downloads a > preamble and a resident portion has to exit to the server. In a shared environment like Henry's, though, the health of any particular application doesn't matter as much as guaranteeing that the printer stays in a known, constant state from job to job. -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
izumi@violet.berkeley.edu (Izumi Ohzawa) (12/02/89)
In article <17391@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >persistant paramenters is not the issue here. Any program that downloads a >preamble and a resident portion has to exit to the server. Examples, Microsoft >word, Pagemaker, Ps executive, my Epson emulator, Diablo emulator, All of I am not sure how many of these applications really HAVE TO do exitserver. At leaset, Microsoft Word does it although it is unnecessary. For versions 4 and 5 of MS Word, you can remove the exitserver section from POSTSCRx.INI file, and the program still works fine. I hate it when they do this. Izumi Ohzawa izumi@violet.berkeley.edu
henry@utzoo.uucp (Henry Spencer) (12/03/89)
In article <17391@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >> >may aplications depend on server password to be the default of 0 and will >> >flat out fail. ... >> >> In a shared environment, this is a feature, not a bug. We *want* those >> applications to fail; we do not want them messing with persistent >> characteristics of the printer. They have no damn business doing so anyway. > >I have to disagree with you. Applications do have to do that. No, they don't. They choose to do so, and could (and should) be fixed not to. >... Any program that downloads a >preamble and a resident portion has to exit to the server... Correct. The solution is not to download resident portions, or at least give the user the option of not doing so. You are implicitly assuming that the printer is dedicated to that user and that application, which is unjustified arrogance on your part. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
woody@rpp386.cactus.org (Woodrow Baker) (12/04/89)
In article <1989Dec3.024451.11099@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <17391@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >> >may aplications depend on server password to be the default of 0 and will > >> >flat out fail. ... > >> > >> In a shared environment, this is a feature, not a bug. We *want* those > >> applications to fail; we do not want them messing with persistent > >> characteristics of the printer. They have no damn business doing so anyway. > > > >I have to disagree with you. Applications do have to do that. > > No, they don't. They choose to do so, and could (and should) be fixed not to. > > >... Any program that downloads a > >preamble and a resident portion has to exit to the server... > > Correct. The solution is not to download resident portions, or at least > give the user the option of not doing so. You are implicitly assuming > that the printer is dedicated to that user and that application, which > is unjustified arrogance on your part. Perhaps it is arrogance, but there remains the nasty problem of not being able to reset the password if you somehow screw it up, and the problems that that engenders. I do not work in a netword enviornment. I have the luxury of owning my own postscript printer, that is dedicated to my computer (an AT by the way, running MS-DOS not UNIX), but there are many legitimate reasons to exit the server. Most apps do it, and because they do it, changing the server password is tantamount (spelling?) to throwing the app out. sure, you can go in and change the preamble. It might work. In the case of MS-WORD it checks to see if it has already been loaded. The emulator that I wrote was required to be persistant, as it is being used on a multi-user system, and ALL of the software uses Diablo escape codes. The company wanted the ability to draw forms, but did not want to re-do all of thier software. Especially, since not all customers wanted the Postscript printer (due to the cost). Given the fact that some of the older versions of Postscript (v.23) had bugs in them, and given the fact that the patches had to be downloaded permanently, one must realize that various applications will try to do that. Again, you want the entire system to funtion smoothly, not barf on an app. Certain utilites are also desireable to have. Examples include justification routines, and utility routines. Don Lancasters collection of handy routines is a case in point. The file is 20k or so. One would not wish to download that each time at 9600 baud, better to tuck it under the server so it is there, and so that everyone using the printer knows it. Perhaps the most compelling reason is the erhandler proceedure. Out of all of the thousands of programs that I own and or use, only Pagemaker, MS-word, and Arts and Letters graphics designer use Postscript natively. No other apps use it. I have 3 or 4 custom applications that I have written that use it. The rest of the time, I am writing in Postscript, without the benifit of any kind of tool except the erhandler and a text editor. I flat couldnot function without having erhandlr downloaded persistantly. I don't change persistant parameters in the printer however. cheers Woody > -- > Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology > started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jtkohl@quicksilver.mit.edu (John T Kohl) (12/05/89)
In article <17399@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >... but there are many legitimate >reasons to exit the server. Most apps do it, and because they do it, changing >the server password is tantamount (spelling?) to throwing the app out. sure, >you can go in and change the preamble. It might work. I think a better solution is to lobby the application developers to add an option to their programs that allow a user to specify the exitserver password. This allows the shared environments to be carefully controlled, while allowing people to get useful stuff printed (assuming they either know the password or know how to find the SysOp who does). If the application developers don't put this feature in their application, then find some competitor who does! -- John Kohl <jtkohl@ATHENA.MIT.EDU> or <jtkohl@Kolvir.Brookline.MA.US> Digital Equipment Corporation/Project Athena (The above opinions are MINE. Don't put my words in somebody else's mouth!)
prc@erbe.se (Robert Claeson) (12/05/89)
In article <JTKOHL.89Dec4134209@quicksilver.mit.edu>, jtkohl@quicksilver.mit.edu (John T Kohl) writes:
: I think a better solution is to lobby the application developers to add
: an option to their programs that allow a user to specify the exitserver
: password. This allows the shared environments to be carefully
: controlled, while allowing people to get useful stuff printed (assuming
: they either know the password or know how to find the SysOp who does).
I believe that printer-specific information such as this is supposed to be
retrieved from a PPD file.
But since each printer on the system/network, even if they are of the same
type, would need its own PPD file, I am tempting to use the Adobe-supplied
PPD files (they can be retrieved from the archive-server@adobe.com) as
templates and then copy the appropriate PPD file to a new file with the
same name as the printer (ie, ps00, ps01 etc at our site) and use those.
I believe that I would then be able to freely change the exitserver password
in those files without breaking any conformance rules.
Right or wrong?
--
Robert Claeson E-mail: rclaeson@erbe.se
ERBE DATA ABwoody@rpp386.cactus.org (Woodrow Baker) (12/05/89)
In article <JTKOHL.89Dec4134209@quicksilver.mit.edu>, jtkohl@quicksilver.mit.edu (John T Kohl) writes: > In article <17399@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > > >... but there are many legitimate > >reasons to exit the server. Most apps do it, and because they do it, changing > >the server password is tantamount (spelling?) to throwing the app out. sure, > >you can go in and change the preamble. It might work. > > I think a better solution is to lobby the application developers to add > an option to their programs that allow a user to specify the exitserver > password. This allows the shared environments to be carefully > controlled, while allowing people to get useful stuff printed (assuming > they either know the password or know how to find the SysOp who does). > > If the application developers don't put this feature in their > application, then find some competitor who does! > -- > John Kohl <jtkohl@ATHENA.MIT.EDU> or <jtkohl@Kolvir.Brookline.MA.US> > Digital Equipment Corporation/Project Athena > (The above opinions are MINE. Don't put my words in somebody else's mouth!) yep, that would be a good approach, but no one does. Not even Adobe. All Indians, no Chiefs..... Cheers Woody
henry@utzoo.uucp (Henry Spencer) (12/06/89)
In article <JTKOHL.89Dec4134209@quicksilver.mit.edu> jtkohl@ATHENA.MIT.EDU writes: >I think a better solution is to lobby the application developers to add >an option to their programs that allow a user to specify the exitserver >password. This allows the shared environments to be carefully >controlled, while allowing people to get useful stuff printed (assuming >they either know the password or know how to find the SysOp who does). They know how to find me, and the answer to such a question will be: "exactly *why* does this application need the password?". Since the usual output from these applications is cryptic in the extreme, the answer will probably be "because", and my reply will be "forget it". If application developers want to be told the password, first they are going to have to tell me exactly what they are going to do with it. (Having sufficiently readable output to facilitate confirming their claims would also be a bonus.) Not trusting users is a relatively minor issue; the big problem is that we don't trust applications developers not to screw up our shared printer, given the impressive displays of incompetence they put on in other matters. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cet1@cl.cam.ac.uk (C.E. Thompson) (12/07/89)
In article <1036@maxim.erbe.se> prc@erbe.se (Robert Claeson) writes: > >I believe that printer-specific information such as this is supposed to be >retrieved from a PPD file. > >But since each printer on the system/network, even if they are of the same >type, would need its own PPD file, I am tempting to use the Adobe-supplied >PPD files (they can be retrieved from the archive-server@adobe.com) as >templates and then copy the appropriate PPD file to a new file with the >same name as the printer (ie, ps00, ps01 etc at our site) and use those. >I believe that I would then be able to freely change the exitserver password >in those files without breaking any conformance rules. > >Right or wrong? > Well, the Adobe documentation (section 4.2) describes the *Password entry as "the default exitserver password", but it might not be incorrect to use it in the way you suggest. Section 2.9 suggests that you should build your per-printer PPD files with *Include entries for the standard one. Of course, you have to decide on the question that Adobe has explicitly left undefined: whether the first-encountered or the last-encountered *Password entry is the effective one! Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
piet@cs.ruu.nl (Piet van Oostrum) (12/07/89)
In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
`DON'T change the serverdict password. If for some reason you forget it,
`you will have to send the controller off to get it recovered. Secondly,
`may aplications depend on server password to be the default of 0 and will
`flat out fail. ...
Well, isn't that a very silly thing: a password that you shouldn't change
and should always have the default value. What if one of our students
decide to change it? Which they can do if the password is 0. It shouldn't
be too difficult to keep the password around: write it on a piece of paper
and lock it somewhere. Keep it with your Laserprinter bill, with your tax
administration, write it in your will :=),...
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')mcdonald@aries.uiuc.edu (Doug McDonald) (12/07/89)
In article <2140@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes: >In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >`DON'T change the serverdict password. If for some reason you forget it, >`you will have to send the controller off to get it recovered. Secondly, >`may aplications depend on server password to be the default of 0 and will >`flat out fail. ... > >Well, isn't that a very silly thing: a password that you shouldn't change >and should always have the default value. What if one of our students >decide to change it? Which they can do if the password is 0. It shouldn't >be too difficult to keep the password around: write it on a piece of paper >and lock it somewhere. Keep it with your Laserprinter bill, with your tax >administration, write it in your will :=),... >-- What all this proves is very clear: the latter person has a very good argument: if you leave it 0, a malicious person could set it to a random value. If you change it, the device fails for many purposes. The solution should be OBVIOUS: a jumper on the logic board that forces it to 0 so it can be reset if disaster happens. Or store the value in some sort of CMOS logic that resets to 0 if the battery is removed. So simple. So obvious. So common in some places. Doug McDonald
woody@rpp386.cactus.org (Woodrow Baker) (12/08/89)
In article <2140@ruuinf.cs.ruu.nl>, piet@cs.ruu.nl (Piet van Oostrum) writes: > In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > `DON'T change the serverdict password. If for some reason you forget it, > `you will have to send the controller off to get it recovered. Secondly, > `may aplications depend on server password to be the default of 0 and will > `flat out fail. ... > > Well, isn't that a very silly thing: a password that you shouldn't change > and should always have the default value. What if one of our students > decide to change it? Which they can do if the password is 0. It shouldn't > be too difficult to keep the password around: write it on a piece of paper > and lock it somewhere. Keep it with your Laserprinter bill, with your tax > administration, write it in your will :=),... > -- > Piet* van Oostrum, Dept of Computer Science, Utrecht University, > Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. > Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet > Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') yes, it is a very silly thing. It should not have been a part of Postscript in the first place.
woody@rpp386.cactus.org (Woodrow Baker) (12/08/89)
In article <1989Dec7.151304.649@ux1.cso.uiuc.edu>, mcdonald@aries.uiuc.edu (Doug McDonald) writes: > In article <2140@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes: > >In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >`DON'T change the serverdict password. If for some reason you forget it, > >`you will have to send the controller off to get it recovered. Secondly, > >`may aplications depend on server password to be the default of 0 and will > >`flat out fail. ... > > > >Well, isn't that a very silly thing: a password that you shouldn't change > >and should always have the default value. What if one of our students > >decide to change it? Which they can do if the password is 0. It shouldn't > >be too difficult to keep the password around: write it on a piece of paper > >and lock it somewhere. Keep it with your Laserprinter bill, with your tax > >administration, write it in your will :=),... > >-- > What all this proves is very clear: the latter person has a very good > argument: if you leave it 0, a malicious person could set it to a random > value. If you change it, the device fails for many purposes. The > solution should be OBVIOUS: a jumper on the logic board that forces > it to 0 so it can be reset if disaster happens. Or store the > value in some sort of CMOS logic that resets to 0 if the battery is removed. > So simple. So obvious. > > So common in some places. > > Doug McDonald yes, except to Adobe. (no offense intended)
rodgers@csc.wcc.govt.nz (12/10/89)
In article <17422@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > In article <2140@ruuinf.cs.ruu.nl>, piet@cs.ruu.nl (Piet van Oostrum) writes: >> In article <17380@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >>> `DON'T change the serverdict password. >> >> Well, isn't that a very silly thing: a password that you shouldn't change >> and should always have the default value. What if one of our students >> decide to change it? Which they can do if the password is 0. It shouldn't >> be too difficult to keep the password around: write it on a piece of paper >> and lock it somewhere. Keep it with your Laserprinter bill, with your tax >> administration, write it in your will :=),... > > yes, it is a very silly thing. It should not have been a part of Postscript > in the first place. The fact is that exitserver is *not* a part of the PostScript language. Try looking it up in the red book. In some editions, its not there at all. In my edition its in the appendix about the LaserWriter where it says: The special operators are intended for use by human users or by host software carying out user requests; ordinarilly, page descriptions should not refer to them, since doing so would impair portability of those descriptions. So there is no guarantee that exitserver exists on all implementations or that if it does that the password will be 0. A case in point is the DEC LN03R ScriptPrinter. This does have exitserver but the password is a string not an integer. The default is (LN03R). I couldn't change the password to 0 if I wanted to so any application that relies on it being 0 is destined to fail. On the other hand, I do agree that exiting the server loop is sometimes a very desirable thing to do. On the other hand, it is often undesirable. Properly written software should give you a choice and if you decide to do it, it should let you tell it how to go about it. On the whole changing the exitserver password is a very good idea. Passwords are there as a security measure after all so what is the point of having a password everyone knows and let's face it, a malicious user who knew could do some real harm. If changing the password also causes poorly written software to fail then that is a bonus. As Piet van Oostrum says, forgetting the password is not really an issue. Can you imagine a Unix sysadmin who decided not to have a root password for fear of forgetting it? -- Mark Rodgers Computer Services Section rodgers@wcc.govt.nz Wellington City Council Telephone (04) 733-130 P.O.Box 2199, Wellington, New Zealand