🚀 go-pugleaf

In <1992Nov12.153918.12371@usiva.com> brooks@usiva.com (Lyle D. Brooks) writes:

>So what makes for the best PostScript??

>a) DSC conformance
>b) Size
>c) Performance
>d) Readability
>e) Viewing
>f) None of the Above

 1) Nice postscript files don't make assumptions about what kind
    of printer they're going to be printed on. This means don't
    don't expect the CTM to have any particular form. It also 
    means never use setmatrix to set it to an arbitrary matrix.
    Things like clippath, should not be used to try and figure
    out pagesize, etc. either. This stuff is for the most part
    in Appendix I of the Red Book 2/e.

 2) I think some of the best (nicest) postscript output I've seen
    is Adobe Illustrator (perhaps not surprising considering
    the people responsible for it.) This is of course a personal
    opinion formulated through considerable experience working
    with the postscript generated by Illustrator '88 and 3.0. 
    Mainly, I can't remember any time I leaped up from my terminal
    and ran around the room swearing at whoever wrote this 
    stupid, ignorant @$%! piece of code.

 3) Some of the worst postscript I've seen was from PC programs.
    (CorelDraw comes to mind.) Mathematica was responsible for
    the comment about not expecting the CTM to have a particular 
    form. 

 4) Good postscript code can be as compact as you like, and have
    as much "algorithmic" cleverness as you want. All I ask for
    is a few comments in the header so I can see what you're doing
    if I need to change something for some reason. DSC conformance
    is very useful. We (and other people I'm sure) are starting to
    make more use of filters that automatically add fonts, procsets,
    etc. Performance is only an issue if you produce code that's
    noticably slower than you'd expect given the size of the file,
    output produced, etc.

 5) I work for a typesetting company. For me, bad PostScript
    is postscript that doesn't print out right on some particular
    device, or can't be inserted into another postscript file
    without being modified or "fixed." The things mentioned
    in 3 are some of the ones I can remember swearing at.


					Aaron Sawdey
					Publication Services, Inc.
					1802 S. Duncan Rd.
					Champaign, IL 61821
					aaron@pubserv.com (email only)

In article <1992Nov12.153918.12371@usiva.com>, brooks@usiva.com (Lyle D. Brooks) writes:
> So what makes for the best PostScript??
> 
> a) DSC conformance
> b) Size
> c) Performance
> d) Readability
> e) Viewing
> f) None of the Above
> 
> Any opinions??

DSC conformance is the most important feature in any computer-generated
PostScript. And this means real DSC compliance, no just using the bits that
you want to and ignoring the others, or changing the comments to suit you
(e.g. removing the label from %%Page: listening, Sun?). It also means putting
the correct headers on documents (Microsoft Word for Windows 2.0 produces
multi-page documents claiming to be EPSF; they haven't read page 709 of the
Red book (2nd Edn.)). Most of the problems I have with documents come down to:

1) Bad %%BoundingBoxes. If you don't have one, don't set it, and don't claim
   to be EPSF. Don't use reals, because they're supposed to be ints.

2) Bad page encapsulation. If you're pages aren't encapsulated completely,
   don't claim to be DSC compliant, or fix it so that they are encapsulated.

I'm currently revising my PSUtils package, and am implementing an ad-hoc
parser for DSC comments. I thought about using Yacc and lex, but there are too
many awkward bits to deal with (e.g. unbracketed text tokens containing just
digits, %%+ comments). The DSC conventions are not very hard to read and
interpret (there are a few unclear areas, such as which comments can be nested
inside others), so there is no excuse for any PostScript developer not to
produce DSC-compliant code.

a.
--
Angus Duggan, Department of Computer Science,	| PSUtils is available from
University of Edinburgh, The King's Buildings,  | ftp.dcs.ed.ac.uk in pub/ajcd.
Mayfield Road, Edinburgh EH9 3JZ, Scotland.	| selects, n-up, booklet & more
INET: ajcd@dcs.ed.ac.uk | JANET: ajcd@uk.ac.ed.dcs | PHONE: +44(0)31 650 5126

In article <1992Nov12.153918.12371@usiva.com>, brooks@usiva.com (Lyle D. Brooks) writes:
> So what makes for the best PostScript??

I nominate, xfig for creating the best PS files.  My spooler program has the ability
to set the matrices for landscape, portrait and 2-up printing for each request it
processes.  Xfig is the ONLY application I have come across that generates a PS
file that works in each orientation, no matter how complex the page.

I wouldn't have a problem with other applications that don't conform to the DSC, but
I wish they wouldn't put '%!PS-Adobe' at the beginning of the file, as if they were.

								/nt

This may be a dumb questions, but is there a psnup program that
works with PostScript file which itself contains EPS files?

I tried the pnsup from wuarchive.wustl.edu but it didn't work
with included EPS graphics (I mean it didn't shrink the graphs).

Any pointers will be appreciated.  Thanks!
-----------------------------------------------------------------------
Pinghua Young, Department of Economics        pinghua@Econ.Berkeley.EDU 
University of California at Berkeley        pinghua%econ@ucbcmsa.BITNET 
Berkeley, California 94720, U.S.A.   ~{C@9z2.?K@{<SV]4sQ'>-<CO5QnF=;*~}

Talking of which, why are there still losts of programs around that
understand DSC 2.0, but not DSC 3.0? Hasn't it been two or three years
since the revision was made?  I am thinking particularly of page imposition
software (can ANY read DSC 3.0?), PostScript previewers etc.

Berthold K.P. Horn
Cambridge, Massachusetts, USA

bkph@kauai.ai.mit.edu (Berthold K.P. Horn) writes:
> Talking of which, why are there still losts of programs around that
> understand DSC 2.0, but not DSC 3.0? Hasn't it been two or three years
> since the revision was made?  I am thinking particularly of page imposition
> software (can ANY read DSC 3.0?), PostScript previewers etc.

Ghostview (an X11 user interface to ghostscript) understands all versions
of the DSC.  In fact it will properly parse many non-conformities as well.
The only known deficiency is that although it does recognize the
"%%PageOrder: Special" comment, it does not give the document the special
treatment requested.  I plan to remedy this in the next release.

Ghostview-1.4.1 can be obtained via anonymous ftp from
ftp.cs.wisc.edu:/pub/X/ghostview-1.4.1.tar.Z.

...Tim

          Tim Theisen           Systems Programmer
Internet: tim@cs.wisc.edu       Department of Computer Sciences
    UUCP: uwvax!tim             University of Wisconsin-Madison
   Phone: (608)262-0438         1210 West Dayton Street
     FAX: (608)262-9777         Madison, WI   53706

(Sorry I can't quote from the original article--this newsreader is
somewhat primitive....)
As far as the worst PostScript goes, I'd say that Finale (a music
notation program for the Macintosh) has to win the prize hands down.
I'd even go so far as to say that it's the worst programming I've
ever seen, and I'm including my own feeble attemps at BASIC on an
Apple II almost a decade ago.

What makes PostScript "good"? I'd say that, first of all, it must
conform to the DSC. Even hand-written code can do this quite nicely,
and it gives a good structure to the program. Beyond that, my personal
preference is for short, highly-tuned code that (hopefully) executes
quickly. Rather than individually draw a hundred squares of varying
shades of gray on the page, as in a color calibration sheet, I'd try
to get the whole thing in a single line with a couple of for loops.

I generally don't like to see things repeated in any computer language.
If you can type out the same line, with minor modifications, a dozen
times to get what you want, the computer can probably do the same thing,
but quicker, if you just have it loop. Most machines now have some sort
of instruction or data cache that make such things highly efficient.

Of course, all this must be balanced with the realities of the situation.
If I needed to get something done in the next five minutes, I'd probably
use cut-and-paste, and figure the extra interpretation time is worth it.

In <92322.131958AUBXG@ASUACAD.BITNET> AUBXG@ASUACAD.BITNET (Ben Goren) writes:

>...
>As far as the worst PostScript goes, I'd say that Finale (a music
>notation program for the Macintosh) has to win the prize hands down.
>I'd even go so far as to say that it's the worst programming I've
>...
So you've never used Calligrapher then :-)

Calligrapher is an ST wysiwyg word processor, which, I am told, drivers
LaserJets fairly well.  Unfortunately, the PostScript driver is terrible.

A few examples (some are bugs, some are just bad PostScript):

1. If using a font that is not built in to your printer, the driver does not
   download a definition for the font, then refer to that definition to paint
   characters.  Instead, it explicity draws the outline of each and every
   character, fills it, draws the outline again, then strokes this.  Thus
   each character in the output takes, typically, 4 Kbytes of PostScript.

2. The coordinates for the lines used to draw the character outlines
   are frequently out by 2 points or so, making the characters look like
   they're printed on a 60dpi printer, not 300, 1200 etc.

3. It will not draw any characters not in the Level 1 Standard Text
   Encoding.  When asked to print a copyright symbol, it printed a plain c.
   When I complained, the authors (Working Title) sent a new driver that
   still put out a standard letter c, but then drew a thick polylined-circle
   around it.  This looks really messy (the circle is much to heavy compared
   with any of the fonts used for the c character).  Working Title flatly
   refused to amend their driver to either use the (c) character from
   a Level 2 coding vector, or to output the (c) from the Symbols font.

4. Rounded boxes are drawn with the wrong radii for the corners, so 
   the corners do not join properly with the straight edges.

5. A good number of the symbols are mapped incorrectly, so what appears
   on the screen as an apostrophe comes out on the printer as a cent.

6. The GEM fill patterns are rendered VERY inaccurately; anyone who has
   access to both Calligrapher and TimeWorks Publisher 2 will find it
   interesting to compare the output.  The 

7. It does not generate *any* DSC directives.

8. Every character is positioned independently.  (For example, 'abc'
   would appear as something like (a) x y moveto show (b) x y moveto ...
   instead of (abc) x y moveto show.  Apart from generating larger
   PS files, it exposes Calligrapher's errors in character positioning,
   and they are not always spaced out correctly.  By using the (abc) form,
   any spacing errors would be inter-word only.  (Obviously, it would
   be better if it got all the character positions correct in the first place).

9. And zillions of other bugs, inefficiencies and wierdos that I won't
   waste further space and time on for now...

-- 
+---------------------------------------------------+
| David Stevenson  djs@jet.uk   Tel: +44 235 465028 |
+---------------------------------------------------+
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.

djs@jet.uk (David J Stevenson) writes:

>In <92322.131958AUBXG@ASUACAD.BITNET> AUBXG@ASUACAD.BITNET (Ben Goren) writes:

>>...
>>As far as the worst PostScript goes, I'd say that Finale (a music
>>notation program for the Macintosh) has to win the prize hands down.
>>I'd even go so far as to say that it's the worst programming I've
>>...
>So you've never used Calligrapher then :-)
>
I don't know how they do it, but MicroSoft Project is right up there with
the worst of them.  When drawing a large grid, it seems to draw each grid 
element as a separate graphic... it takes forever.

-- Michael Slade, Datavision Technologies