rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (11/23/89)
After seeing yet another sample of *lousy* PostScript generated by an application (this one Windows Designer), I'm very upset. This particular application makes *no* effort to comply with any structuring conventions. It even generates an unprotected call to `a4'. I get numerous bug reports---90% of the distill down to problems with the application generating the PostScript. What I propose is that Adobe (or some enlightened soul) attempt to write a `validation' program. This simple C program would read in a PostScript graphic following the structuring conventions and generate another, with the included graphic scaled and rotated to perhaps halfsize in the middle of the page. The output PostScript would also have drawn some things before and after the included graphics. And this C program would parse and check the input graphic appropriately. Then, if an Application claimed to generate `PostScript', especially for potential inclusion in other programs, its generated output should be capable of being sucessfully filtered and scaled by the above C program. This C program should be fairly simple and thus portable, and would be a tremendous boon to those attempting to support products that include PostScript images; by simply running the program above with a troublesome graphic, the fault could be quickly isolated. In addition, this C program could serve as the basis for an application's PostScript importing code, showing things done correctly. I'm sick of dealing with Adobe's poorly written and changing structuring conventions, and even more so with applications that don't make even an effort to comply. Comments or thoughts?
mike@cs.keele.ac.uk (Michael A. Green) (11/23/89)
From article <12877@polya.Stanford.EDU>, by rokicki@polya.Stanford.EDU (Tomas G. Rokicki): > After seeing yet another sample of *lousy* PostScript generated by an > application (this one Windows Designer), I'm very upset. This particular > application makes *no* effort to comply with any structuring conventions. > It even generates an unprotected call to `a4'. > > I get numerous bug reports---90% of the distill down to problems with the > application generating the PostScript. > > In addition, this C program could serve as the basis for an application's > PostScript importing code, showing things done correctly. > > I'm sick of dealing with Adobe's poorly written and changing structuring > conventions, and even more so with applications that don't make even an > effort to comply. Comments or thoughts? Good idea! I was the first person here to get interested in PS (years ago) and as such am considered the resident 'guru'. One of the nasty side effects of this is being called upon (constantly) to sort out problems in printing "PostScript" generated by various programs. Many/most of our PC programs for word processing/cad/etc and several on our Sequents/uVaxes/Suns produce so called "PS". It has taken me many hours of tedious debugging to find the problems with the PS these programs produce. The most common problem is with tacky/inaccurate/incomplete prolog files, these are hard to find problems and it is even harder to try and work out what missing commands are supposed to do. The worst offenders by far are programs that produce EPS output for loading into other programs/files. On most of these I give up and suggest a 'phone call to the distributor to sort it out (I don't have the time any more). I think that it is about time that a validation suite was provided, it would certainly sort the real PostScripters from the hacks! --Mike -- |Michael A. Green. |JANET: mike@uk.ac.keele.cs | |Department of Computer Science |BITNET: mike%cs.kl.ac.uk@ukacrl | |University of Keele, Keele, |ARPANET:mike%cs.kl.ac.uk@nsfnet-relay.ac.uk| |Staffordshire. ST5 5BG. U.K. |VOICE: +44 782 621111 ex. 3357/3347 |
spage@cup.portal.com (S spage Page) (11/24/89)
>> [ Need a PostScript verification/test tool. ]
I agree entirely. I use Aldus Freehand to produce diagrams for insertion in
Word 5.0 for the PC, using IBM-format EPS as the import mechanism. This works
fine most of the time, but every 30th diagram crashes the printer with
savelevel problems. Or only some of the PostScript is incorporated. Or
nothing appears. Naturally, each company blames the other. I'm considering
buying another high-end package (Lotus Manuscript?) just to have a third
party to check EPS files against.
Adobe bears a lot of the responsibility for the successful use of its
files as interchange standards, and they should shoulder that burdern by
providing developers and sophisticated users with appropriate tools, test
programs and utilities. Aldus is in a similar situation with the TIFF
spec, and you can download a package of C code and a dump program from
Compu$erve if you're having problems with TIFF. (And boy, can you have
problems with TIFF!)
It would help if the user community identified programs which output good
or bad PostScript. We'll never get this information from software reviews
(can you imagine "professional" reviewers even looking at a PostScript output
file??). Here are my two cents:
Word 5.0 for the PC: a joke. Uses exitserver, not conformant, no
optimization.
Aldus Freehand: generally excellent. Simple, readable output. Includes
its whole header even if the file doesn't need all the routines.
=S Pagespqr@ecs.soton.ac.uk (Sebastian Rahtz) (11/25/89)
>>>>> On 23 Nov 89 01:46:45 GMT, rokicki@polya.Stanford.EDU (Tomas G. Rokicki) said: > a `validation' program. This simple C program would read in a PostScript > graphic following the structuring conventions and generate another, with > the included graphic scaled and rotated to perhaps halfsize in the middle > of the page. The output PostScript would also have drawn some things pathetic, isn't it, but I use TeX for this purpose, to read in an apparently valid bit of EPS and see if it can be scaled and placed on the page mixed with new input. doesn't answer your question, and I agree with you that what you describe would be an excellent thing to have around. -- Sebastian Rahtz S.Rahtz@uk.ac.soton.ecs (JANET) Computer Science S.Rahtz@ecs.soton.ac.uk (Bitnet) Southampton S09 5NH, UK S.Rahtz@sot-ecs.uucp (uucp)
ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar 7420) (11/25/89)
In article <12877@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: > >I get numerous bug reports---90% of the distill down to problems with the >application generating the PostScript. > >What I propose is that Adobe (or some enlightened soul) attempt to write >a `validation' program. This simple C program would read in a PostScript >graphic following the structuring conventions and generate another, with >the included graphic scaled and rotated to perhaps halfsize in the middle >of the page. I think that this is an excellent idea, as I often experience the same problem. I was recently horrified to discover that a very popular PC word processor (whose name I am not willing to divulge in case of legal retribution) produces code that would have to be deliberately badly programmed. For instance, for every word it prints, it recalculates the width of the space, ignoring the fact that the width of the space does not change unless the font is changed. This and other inadequacies mean that my printer (a NEC LC-890) takes over a minute to print even the simplest of pages! Users should not have to put up with this sort of incompetent programming, and if I were Adobe, I would be extremely concerned that some users would put the blame on postscript, rather than at the feet of the incompetent programmers where it belongs. I am now faced with the possibility of rewriting the printer driver for this program, and something that nobody should have to do after spending $600 on any program. The availability of such a validating program would, at the very least, allow the programmer to evaluate the efficiency of the code they are producing. Disclaimer: The opinions expressed here are my own, and bear no relation to any possessed by any other member of Macquarie University, or of the policies of the university itself. D
moore@RIGEL.FAC.CS.CMU.EDU (Dale Moore) (11/27/89)
>After seeing yet another sample of *lousy* PostScript generated by an >application (this one Windows Designer), I'm very upset. ... I agree. Many utilities that generate PostScript assume that the output will be done on an Apple LaserWriter. Or worse yet, assume that some specific prelude has been down loaded to the printer in advance. >What I propose is that Adobe (or some enlightened soul) attempt to write >a `validation' program. This simple C program would .. I don't see how it could possibly be simple. From what little I understand of PostScript, it would have to be nearly the entire interpreter. Plus additional code for dealing with document structuring conventions. >I'm sick of dealing with Adobe's poorly written and changing structuring >conventions, and even more so with applications that don't make even an >effort to comply. Comments or thoughts? The Adobe PostScript Document Structuring Specification is written nearly as well (or should I say nearly as poorly) as most other technical documents. Consider your favorite programming language, whether it be PostScript, C, or Pascal. Nearly anyone can read the language spec, and say... "Gee I think I understand." The only problem is when you write some code, and try to run it through your compiler or interpreter. The machine will point out your most obvious mistakes. Perhaps we, and the developers whose software generate PostScript, rely too heavily on the machine to expose our shortcomings and misunderstandings. I see two ways of dealing with companies that generate bogus PostScript. - Not buy their products, and let them know why. Or tell the company that you disrecommend their product. - Publish a list of software that generates bogus PostScript and what in particular is wrong with the PostScript that they generate. The difficult part with this is getting it published, as most trade rags will never, ever print a review that will not show the product in the best possible light. When is the last time you read a review that said "This product is a real peice of crap." Maybe it should be a bit like those consumer digest magazines. I just don't think that Adobe can, or should be, the police force for every possible company that generates or pretends to generate PostScript. What they should, and perhaps already do, is to consult and offer tools or services that will help the software house generate better more robust PostScript. I suspect that we are in agreement here. But where we differ is that I think that Adobe might want to keep these tools proprietary and as trade secrets. And I suspect that you would like to see them brought out into the public. Oh well, I've rambled for much too long. Dale Moore
henry%angel@Sun.COM (Henry McGilton -- Software Products) (11/28/89)
The several people who have posted notes on `bad'
PostScript certainly have some good points.
Before getting into all the problems I've personally had to
debug, here are a couple of philosophical issues:
1. A PostScript program should have ZERO assumptions built
in as to where it will end up. That means that the
writer should certainly NOT assume the resulting
PostScript will end up being printed on any kind of
printing device -- it might just be included as part
of another PostScript program.
2. Most of the `bugs' I've actually debugged were a result
of the programmer either violating issue (1) from
above, apparently not reading the PostScript
Reference Book, or apparently having read the book
and having failed to implement PostScript according
to the book.
PostScript against which I've had to build firewalls
included some or all of the following problems:
Control-C characters at the end of the PostScript file, on
the assumption that the PostScript was destined for a
printer in an environment where there is no print manager.
For all you people out in PC/MS-DROSS land, DO NOT put
control-C characters at the end of EPS files. The Adobe
Red Book is very clear on this topic. This horse was
flogged beyond death some time ago, and as far as I'm
concerned, Adobe's position that control-C characters are
in the purview of the print manager not the application, is
the correct one. Now, let's bury the horse once and for all.
Control-Z characters at the end of the PostScript file, on
the assumption that the PostScript was destined for a text
file in PC environment. Control-Z is an end of file only
in the MS-DROSS and CP/M world. Other systems (such as
UNIX) do it right. End of file is a state of mind, not a
special character. DO NOT put control-Z characters at the
end of EPS files.
EPS 1.2 files containing a binary header, but no preview
image. Look chaps, if all that's in the file is the
PostScript, why bother with the binary header at all? The
Adobe spec is not crystal clear on this issue, I admit, but
it never occurred to me that somebody would include the
binary header just so they could indicate that the preview
image didn't exist.
PostScript files consisting of one giant line, as long as
the file, with no reasonable line breaks. Most editors
(certainly vi) can't deal with huge one-line files, and
I've had to retrain my fingers to use EMACS. I've seen
plenty of these weirdos. If you couldn't edit the
PostScript, how in the world did you developers out there
ever debug the PostScript? From what I've seen, you
probably didn't.
Using the { < . . . > } sequence to get sampled image data
onto the stack as the procedure argument to the image
operator. This only works up to a certain point, and then
breaks, resulting in plenty of debugging time on the part
of the consumer, not the developer. Use the
readhexstring operator and do it right next time, please.
Using printer-specific setup procedures like letter and
legal and a4 and so on. Even if you really really must
do these things, at least put them inside a save/restore pair.
Wiring the characteristics of specific printers into your
application. I recently had to shred the innards of a
program that assumed the generated PostScript was destined
for American standard letter size paper on an Apple
LaserWriter model I, complete with 1/4 inch margins around
the edges where the engine won't mark. Use the Printer
Description Files that Adobe supplies. Course, if UNIX had
anything like a print manager, a lot of these problems
could be taken away from the applications.
Failing to realise that the clip operators add to the
path and don't do an implicit newpath the way that
stroke and fill do.
Not using dictionaries when they should.
By far the most frustration has come from the existence of
an old, out of date, obsolete, ossified, interim version of
the EPSF 2.0 specification that somehow escaped from
Adobe when it was only half assed. By the time the
specification was fully assed, every implementor and their
dog had written EPSI to that specification, resulting in
lots of trouble for those who had waited patiently for the
real 2.0 specification. All you people out there who have
the EPSF 2.0 specification dated 11th May 1987, would you
do us all a favor: eat the damned thing with a champagne
chaser, then ask the Adobe file server for the latest 2.0
specification dated sometime in 1989, and implement to that
specification. Would you all do that, please?
............... Henry
+------------------+------------------------+---------------------------+
| Henry McGilton | I saw the future, | arpa: hmcgilton@sun.com |
| Sun Microsystems | and it didn't work. | uucp: ...!sun!angel!henry |
| Mt. View, CA | | |
+------------------+------------------------+---------------------------+rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (11/28/89)
> >What I propose is that Adobe (or some enlightened soul) attempt to write > >a `validation' program. This simple C program would .. > I don't see how it could possibly be simple. From what little I understand > of PostScript, it would have to be nearly the entire interpreter. > Plus additional code for dealing with document structuring conventions. Nope, I'm thinking of just an empirical test. The C program would not even look at the PostScript, it would just interpret and strip or pass along the structuring conventions, as appropriate. (It should check them for validity to a certain degree as well.) But it would act as a minimal importation program---ie, generate some trivial printed output of its own both before and after the imported graphic, and scale, position, and possibly rotate the included graphic appropriately. It could serve as the basis of a program's EPS importation ability. > The only problem is when you write some code, and try to run it through > your compiler or interpreter. The machine will point out your most > obvious mistakes. This doesn't work for the structuring conventions. Most spoolers only interpret/handle/check a few of the structured comments, and many incorrectly handle some of the ones they attempt to interpret. Heck, many spoolers probably completely ignore the structuring conventions; this is why we are in the existing sad state. Hell, old Adobe interpreters used to allow you to do all sorts of illegal things---like modifying supposedly read-only font dictionaries. > Perhaps we, and the developers whose software generate PostScript, rely > too heavily on the machine to expose our shortcomings and misunderstandings. Absolutely---empirical programming strikes again. > I just don't think that Adobe can, or should be, the police force for > every possible company that generates or pretends to generate PostScript. No, but Adobe, as the highly-paid standard bearer, has the responsibility to establish the standards. This is the basis of my complaints with Adobe. PostScript is a great contribution to computing, but it needs care and attention. It needs rigidly defined standards and test suites to check those standards. It needs carefully designed extensions to meet new needs. But Adobe sat on its hands for all the years it had the monopoly. Adobe has done very little for PostScript since the original LaserWriter interpreter. Now that the clones are coming, PostScript is in danger of splintering, due to almost-compatible interpreters and differing interpretations of the loosely-worded specifications Adobe has made available. The elegant, clean, beautiful PostScript language is becoming a rat's nest, mostly due to the poor structuring conventions. > What they should, and perhaps already do, is to consult and offer > tools or services that will help the software house generate better > more robust PostScript. I suspect that we are in agreement here. Sounds good to me. > But where we differ is that I think that Adobe might want to keep > these tools proprietary and as trade secrets. And I suspect that > you would like to see them brought out into the public. By keeping these tools proprietary, they are hurting their own standards. The shitty PostScript generated by today's applications illustrates that beyond any doubt. > Oh well, I've rambled for much too long. I sure as hell haven't. But your points are good, and help temper the violence of my anger. See you on the bit stream! > Dale Moore -tom
nelson@sun.soe.clarkson.edu (Russ Nelson) (11/28/89)
In article <128431@sun.Eng.Sun.COM> henry%angel@Sun.COM (Henry McGilton -- Software Products) writes:
Using the { < . . . > } sequence to get sampled image data
onto the stack as the procedure argument to the image
operator. This only works up to a certain point, and then
breaks, resulting in plenty of debugging time on the part
of the consumer, not the developer. Use the
readhexstring operator and do it right next time, please.
Yes, if you're going to use {< . . . >}, you may as well use
readhexstring. However, if you need multiple copies of the image, you
pretty much *have* to use /image < . . . > def and then {image}.
Otherwise you have to put multiple copies of the image in the input
stream. At 9600 baud, I'd rather not.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.