NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/postscri/6086

Text File | 1992-12-23 | 4.9 KB | 98 lines

Newsgroups: comp.lang.postscript
Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!csn!raven!rcd
From: [e-mail] (Dick Dunn)
Subject: Re: Justifying strings, how??
Message-ID: <[e-mail]>
Organization: eklektix - Boulder, Colorado
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 23 Dec 1992 08:25:49 GMT
Lines: 87

[e-mail] (peter da silva) writes:
>[e-mail] (Stephen Zisk) writes:
>(justification on the printer...)
>> This works well, but puts the load onto the PostScript interpreter.
>
><stringwidth> seems to be a cheap operator.

Actually, stringwidth is moderately expensive, and can be quite expensive.
The one factor that saves you is the font cache.  Let's take a look under
the hood...

A host program, using .afm files and fairly obvious C code, gets the widths
and runs down the string with a for loop, picking up widths and accumulating
them.  The cost is a handful of machine instructions per character.

A PostScript program gets into the stringwidth operator and runs down the
string with a for loop, picking up characters and adding their widths.  The
cost is similar *except* for what it takes to get the widths.  Let's look
another level down...

If the character is not in the cache, we're in trouble.  We've got a char-
acter code, which is an index into the encoding vector, which gives a name,
which must be hashed to get into the CharStrings dictionary, which gives us
this funky object that must be interpreted.  Now, we only need the width,
which must appear near the beginning (assuming the normal case of a Type 1
font) in an sbw or hsbw operation...but by the time we get to that point,
we're about two orders of magnitude higher in operations-per-character than
the host case.  What saves us is this:  (a) the character has probably
already been rendered once, so it's probably in the cache and we don't go
down this path, or (b) if we get here, the interpreter may go ahead and
render the character into the cache, so that we pay the cost here but not
in the "show" operation which almost certainly follows.

That is, it may appear that stringwidth is cheap under normal circumstances,
but if you didn't do corresponding show's afterward, it might look more
expensive.

If the character is in the cache, we'll do a hash based on the character
code and the current font/matrix combination, drag out the width and
accumulate it.  The overhead isn't bad, but it's probably several times the
cost of a direct host-based loop.

>> For tests, short jobs, and personal use, this is fine, but if you
>> are writing a driver with performance in mind, you should at least
>> consider doing the job on the host.
>
>I don't know about that. I've used text-to-Postscript preprocessors, and
>even on printers with a cheesy 68000 I've got better results in terms of
>page speed letting the printer do this sort of thing...

It's easy for the simple case, hard for the semi-sophisticated case, and
damned-near-impossible for the general case.

>It seems that parsing
>Postscript (breaking up numbers, words, etc) is relatively expensive
>compared to executing the Postscript code...

Is the cost of parsing and managing it separated from the cost of trans-
mitting it?  But even if the transmission time is not a major issue, yes,
there is this per-character overhead that can dominate.  Get down to bound
code, and the picture changes somewhat.

>Personally, I would prefer it if programs made decisions like this as late
>as possible, so I can print a document with a different font (say, my printer
>doesn't handle Palatino and the company is too cheap to buy a softfont)
>without screwing things up too badly.

This would be nice, and it works for simple documents, but how far can you
carry it?  My experience is that it works for *very* simple stuff, but you
hit the wall before you get all you want.  Here's where it goes:  If you
chnage the font, you change the line breaking, which requires hyphenation
on the printer side.  You also change page breaks, which changes the
ToC.  This ends up requiring the file-inclusion (diagrams, EPS stuff) on
the printer side, which means that it has to know how to get files.  There
is a large, uncomfortable middle ground...for example, I can see running
troff on a host machine and shipping PostScript across, or I can see
shipping troff source to a capable printer which knows how to snag the
files it needs, but I don't see much in between.

Formatters written in PostScript (been there, done that!) tend to have
this unfortunate characteristic of "simple things are simple; difficult
things are impossible" and the curve in between has a very uncomfortable
shape.  If anyone sees how to make the middle ground passable, I'd love to
hear how.
--
Dick Dunn    [e-mail]   -or-   raven!rcd    Boulder, Colorado USA
   ...Mr. Natural says, "Use the right tool for the job."