[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Slimming down the drawing API.
From: |
Richard Frith-Macdonald |
Subject: |
Slimming down the drawing API. |
Date: |
Tue, 19 Feb 2002 09:29:35 +0000 |
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.
- Slimming down the drawing API.,
Richard Frith-Macdonald <=