🚀 go-pugleaf

In article <3247@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
|In article <alfred.702678056@dutepp13> AKayser@dnpap.et.tudelft.nl (Alfred Kayser) writes:

|<Sorry for the long include, but psroff as it is installed (version
|<3.x I believe) does optimize output and outputs data in the form of:

|<%!PS-Adobe-1.0
|< ....... Reasonable long header removed ....
|</Times-Roman 10 SetFont
|<137.1(is)X
|<148.5(a)X
|<157.6(filter)X
|<182(which)X
|<211.1(converts)X
|<249.8(gif)X
|<265.6(images)X
|<298.8(into)X
|<319.1(PostScript.)X
|<370.6(The)X
|<390.8(option)X
|<421('-eps')X

|%!PS-Adobe-3.0
|%%Creator: groff version 1.05
|[... other goodies deleted ...]
|(The directory in which temporary \214les will be created.)144 400.8 R .529
|(If this is not set and)5.529 F F3(TMPDIR)3.029 E F0 .529(is set, tem-)2.779 F
|1.04(porary \214les will be created in that directory)144 412.8 R 6.041(.O)-.65

|The above was the tail of the groff output for groff.man.  As you can see,
|many words are placed into the same string output, saving lots of resources
|and file size space.

The difference isn't that big.  Once you start coalescing words, you get
the vast majority of the compression.  Further, this starts becoming
considerably less helpful when full justification is on because spacing
changes, and with groff's kerning, you can't do it all in one shot.
And, of course, font or point size changes breaks this down.

It's actually not that hard to factor in spaces - it would only be a line
or two in psroff.  However, making long optimizations like this will
start exaggerating quantization and truncation errors in the width tables
and placement calculations, resulting in visually obvious screwups.
Especially when, as Peter has done with his Hershey fonts, you guess
at the widths of some of the characters.  While this isn't a big problem
with groff and its PostScript width tables (because of the size scale
business), it becomes much hairier with other width tables.

[Using the same width tables for different devices is somewhat common -
as in xtroff-preview-go-print cycles.  Groff's line optimization can
make the results look horrible.]

During development of psroff, after lots of experimentation, I decided
*not* to do line optimization for these reasons.  Just word.

With the optimizer on, psroff can drive even an old laserwriter at full
rated output speed.  Which was what I was aiming for.  Respectable
compactness, print speed, and robustness in the face of slightly off
width tables.

And, according to reports, psroff execution is considerably faster than
groff's.

Whatever.  Groff is "better" than psroff - most of the time.  But it's
a lot of space, and a lot of effort to port groff.  And psroff does many
things that groff cannot.  Whether the tradeoff leans towards psroff or
groff depends on individual circumstances.  There are people who use
*both* at the same time, ie: groff driving psroff driving Laserjets
or dot-matrix printers.

But it doesn't make any sense to dump psroff simply because the output
postscript is slightly larger than groff's.  And it is only slightly
when psroff's optimizer is on.  Individual character placement
means that the optimizer is off.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca