Slimming down the drawing API.

[Richard Frith-Macdonald]

As Fred pointed out at the weekend, we have quite a few DPS functions 
that we don't
actually use, as well as at least one PostScript capability that we 
*will* need to
use, but don't have in the xgps backend.

We accepted a long time ago that we are never going to be able to 
support a full
PostScript interface for all backends - so perhaps we should spend some 
time
rationalising the subset we provide/will provide.

I don't think we should actually use any non-PostScript interface 
between the
front and back ends (with the exception of letting different backends 
implement
different ways of drawing an NSBezier path and an NSImage, for 
efficiency/simplicity)
as I don't think there are any other areas where the data structures 
concerned are
sufficiently complex that conversions would be complicated or 
inefficient.
Actually, I'm not wholly convinced that NSBezierPath and NSImage should 
normally
use anything other than a PostScript api internally - I'd like to go 
over that
issue again in some more detail if someone could explain to me.


I think we can actually get rid of (as far as our public API is 
concerned) DPSshow
and its variants ... and tell users to use the NSStringDrawing 
interfaces.

Inside our string drawing code, we *will* want a PostScript compatible 
interface
for drawing strings and characters, but we need one which will support 
full PostScript
string drawing, not just ascii.

We could have similar operators to those we have at present, but passing 
true
PostScript strings (ie. pointer to memory and length of data stored at 
location)
rather than nul terminated C strings.  Where true dps is available, 
these would
call the DPS function to send the data onto the PostScript stack in the 
server,
while the xgps backend (and similar) would copy the pointer and length 
onto the
local emulator stack, and the show (or a variant of it) operator would 
then use
that data with the appropriate X (or windoze) function calls.