Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!ames!ncar!ico!vail!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.lang.postscript Subject: Re: *COMPLETE* Postscript Description Summary: in defense of Adobe... Message-ID: <1989Dec21.000312.3330@ico.isc.com> Date: 21 Dec 89 00:03:12 GMT References: <28@macuni.mqcc.mq.oz> <17447@rpp386.cactus.org> Distribution: comp Organization: Interactive Systems Corporation, Boulder, CO Lines: 156 background - talking about printer internals... > > >...Doesn't Adobe know that there are people determined to find > > >this kind of stuff out, and its just a matter of time before all their > > >secrets are common knowledge? These aren't "secrets" any more than it's a "secret" that there are rings on the pistons in your engine. They're internal characteristics which are mostly irrelevant to the end user. > > >I find it a bit silly that people are using ROM monitors to find > > >"secret" PostScript commands when Adobe's "red book" claims to be the > > >complete discription of the PostScript language... I find it a bit silly too, but for a reason entirely at the other end of the spectrum. The red book IS pretty much a complete description of the language--meaning that it describes what you can count on, as opposed to what might happen to work, on some printers, sometimes. woody@rpp386.cactus.org (Woodrow Baker) writes: > Ah, but it is also a full fledged computer... Well, PostScript is Turing-complete, and that's important in the sense that it's free of the zillion stupid special cases and restrictions that plague other printer interface "languages". But it's a special-purpose language, and a printer, if you want to consider it a computer, is special-purpose also. It's not intended for general computation. Folks like to say "but think of all the cycles just going to waste..." Well, think of all the office space that goes to waste 3/4 of the time, and think of all the cars that sit idle most of the time. It's a specious argument. >...Adobe left a lot to be desired > with the design of PS. Of course, these things come with hindsight... This flies in the face of the experience of almost everyone who has used PostScript for serious work. Adobe's design is carefully thought out, about as complete as could be expected, and has withstood the test of a moderate period of time with almost no need for change to the language. I've found it to be remarkably good. In fact, it seems that people have problems with PostScript and start finding it inadequate when they start trying to use it for something it wasn't intended to do. To that, the only sensible answer is "don't do that." If you're trying to use a wrench as a hammer, you're going to find that it's inadequate. The solution is not to redesign the wrench. > ...In > addition the preponderance of PS printers are 300 dpi lasers... Today, yes. So what? That could change in a couple of years. Do you want to design in obsolescence (AND machine-dependence)...in *spite* of Adobe's best intentions??? Fella, they're trying to help you. They're trying to keep you from hurting yourself (and others). > ...Why was a PATHBLIT or BITBLIT operator > left out? It would imensely speed up many things... What would it speed up, by how much, and how do you really know that? Remember that printers are doing text most of the time, and PostScript interpreters are generally very good at that. I've found that the imaging operators are reasonable when you're doing 1:1, which is analogous to the bitblt case. It's a good idea to leave out bitblt anyway, since (as many folks have noted in the past decade or so:-) it doesn't generalize usefully when you add gray scale or color. >...Yes I know you can fake it > by faking the font mechanism, but there appears to be a finite limit to the > amount of space that gets chached... ??? Do you expect an infinite cache? I can't make sense of this. >...The ability to read the memory map is > also missing... It's not missing from a language which doesn't assume the existence of a memory map. PostScript is NOT an interface language for a 300 dpi printer. Think about the common case of layout and proof at 300 dpi, then going to a phototypesetter for final output. Do a quick calculation of how much memory it takes to map a page at 2540 dpi! >...The ability to do a transparent overlay (the imageing model > uses opaque overlays, ignoring the need for transparent overlays),... ...something other than imagemask and/or the font mechanism? The PostScript imaging model is a painting model. It's consistent. If you want transparent overlays (which really aren't that common) you can prepare them. Transparency isn't a simple idea. >...the ability > to peek and poke to memory and screen ram... This is getting ridiculous! At the risk of putting words in Adobe's mouth, I DO NOT believe they were trying to build you a hacker's toy. They were trying to produce a tool for getting real work done. >...The ability to have **8 bit transparent** interface access > bidirectionaly,... The design was to make the language expressible in 7-bit ASCII. That's a specific decision. > The rom monitor is useful for taking apart PS code, and finding the memory > maps of the printer. In the hands of a good pgmr, much can be revealed > that will be useful... This is not what a "good programmer" would do. This is what an amateurish hacker would do. > Device independance is an admirable goal, but documenting the special stuff > and non-portable i.e. not device independant stuff would make a ***LOT*** of > people much happier... I don't think it's that many people. PostScript is incredibly useful just as it is...and in fact, I'm glad that the language is designed so carefully to be printer-independent, resolution-independent, etc. It minimizes the hassles I have to deal with. >...Other companies will, if you won't, and you'll loose > users... > ...IF Adobe doesn't follow suite, > they have an extrememly good chance of having the standard torn from thier > hands, and loosing market share... If they start introducing printer dependencies, back doors, dark corners, etc., they won't have a standard at all. There is a mechanism for intro- ducing the few needed printer-specific characteristics as operators you can test for and use. You may have noticed that Adobe is not exactly losing market share! It's important to understand that the specification of the language not only defines what is IN the language but, by omission, tells you what is NOT in the language. If you happen to find things you can do with a particular implementation, but they're not defined in the language defi- nition, you're outside the language and looking for trouble. The spec tells you what you can count on. >...It would be the most prudent thing to > ****LISTEN**** and respond to the user community. Well, OK, I'm part of the PostScript user community too, and I want Adobe to listen to me too! I think PostScript is doing fine as it is, and I want it to stay as a useful tool for serious use. I *don't* want it to be turned into a PC-world hacker toy. I don't want all manner of printer- specific gunk to be part of the language (tho I think there's small danger of that). -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."