CompuServe Messages

Mike, I have to disagree with you. PostScript was designed as a very extensible and flexible language. One of the most importatnt design aspects is the ability to save the graphics state without any overhead penalties. This allows an importing program to handle redefining, nullifying, and otherwise handling just about anything it wants to import. Adobe has made very strong recommendations regarding structuring conventions. And these are very important to avoid choas in the writing of various kinds of spoolers and other utility programs, as well as the ability of disparate applications to know what to expect from a 'properly behaving' incoming file. However, _none_ of the structuring conventions prevents a generic PostScript program from becoming an importable entity. It is impossible to anticipate the final use of a PostScript program, although the _intended_ use may be very clear at the time of its creation (ex. a file destined for an imagetter). This is part of the beauty of the language. Certainly, adhering to all the conventions re EPS files makes handling of files which are _always_ intended to be imported into another file much easier. Generic PostScript files can and _should_ be designed so that their eventual use can _always_ be determined by the environment in which they are finally placed, whether that environment is a PostScript output device, or the unanticipated inclusion into another file. As a matter of fact if "simply wrapping any old PS file with structured comments won't do", there is every reason to believe that the original file is suspect. It should _not_ be that hard to accomplish the encapsulating. That is, the incoming PS file should not use commands in a way that creates havoc in any environment. The single most important advice I have read re PostScript programming (or any other computer programming, for that matter) is, "speak in whispers, leave no footprints." Rich