Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: "David S. Chappell" <David.Chappell@mail.trincoll.edu> Date: Mon, 25 Oct 1999 14:45:31 -0400 Subject: Re: PPR: DSC parsing problem? At 04:50 PM 10/22/99 -0400, you wrote: >Well, I've looked around for a solution to this and have come to the >conclusion that since my HP printers don't mind having "(atend)" in the >resource list and my current printing software (Transcript 4.0 from >Adobe) doesn't mind, then PPR shouldn't mind either. At least not for >me. I want to put PPR into production but I cannot until this is >resolved. So, I went ahead and made a patch for it and included that >patch in this e-mail. The printer ignores all lines starting with "%". I suppose Transcript keeps quite about resources it can't supply. PPR will do this too if you invoke ppr with the -P trusme switch or there is a line which says "%%ProofMode: TrustMe" in the header of the PostScript file. >Basically, I just changed the handle_atend() and trap_atend() functions >in ppr_dscdoc.c. Before, they would only check for "(atend)" >immediately following the DSC comment. Now, they go through the >resource list of the comment, breaking when it finds an "(atend)". It >issues a WARNING_SEVERE if the (atend) is not the first (and only) >argument to the DSC comment, then sets the atend_flag and continues on. >I don't know for sure if this is proper, the Red Book doesn't mention >anything about "(atend)" being declared in the resource list, at least I >couldn't find any reference. That sounds like a reasonable patch. I can't decide whether to use it or not. I don't really like clogging the source code with weird exceptions for broken programs. What makes it worse, is that these programs get upgraded, and when I modify the code, I can never tell if I have broken all the exceptions. Lately, I have been writing little Perl scripts which step in and fix things up enough. However, PPR examines the "%%Creator:" comment to determine when these little scripts are necessary, but here Acroread is claiming to be FrameMaker! >I'm also wondering if this is FrameMaker's or Acrobat's fault in the >first place for generating this weird postscript. Seeing that Acrobat >3.02 generates it fine, but Acrobat 4.0 doesn't, I'm thinking it's >Acrobat's fault. And if that's true, then this should be okay >postscript since you'd think Adobe would be the most authoritative when >it comes to proper DSC conventions. It is Acroread's fault. Unfortunately, most print spoolers completely ignore DSC comments. Those that pay attention only act on a few of them. This means that the DSC comments get almost no testing. Almost all programs generate some erroneous lines. Over the years, I have had to do a lot of work on PPR to make it recover as gracefully as possible from messed up comments. Syntactically legal but false statements are the hardest to deal with. Adobe does better than others, but they still make mistakes. ================================================================ David Chappell David.Chappell@Mail.Trincoll.Edu Computing Center PostMaster@Mail.Trincoll.Edu Trinity College (860) 297-2114 Hartford, Connecticut 06106