Re: Slimming down the drawing API

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> I hope I don't seem to be arguing against Fred ... I don't really intend
> to.
> 
No you did not. This is not some thing personal, it is a discussion
about the best interface between the GNUstep graphical front end and all
its possible backends. (which always includes PS printing!)

> I'm trying to express caution and a desire to maintain/improve backend
> consistency
> while minimising support work required.
> 
Yes, our goal is a interface that is consistent and easy to implement on
all the platforms we aim at. For the xdps backend and for PS printing a
PostScript interface might seem to be the natural choice. But as it
turns out that some of it is a bit clumsy for all other cases.

> Where I say we should stick to the PostScript API, what I mean is that
> we should do
> it as much as is reasonably possible.  ie that we shouldn't introduce
> new APIs for
> the convenience of a single backend.
> 
> Short of making a wholesale change to another API (which I don't
> necessarily view as
> a bad thing, just something that I don't know of any real candidate
> for), I think
> we should examine each case individually with some care.
> 
> It's possible that we may soon find ourselves with a new de-facto API
> anyway -
> 
> Fred says that we don't use the PostScript stack in xgps...
If you are referring to the operator stack you are correct. (As you know
PS is using a number of different stacks and we are using some of them
very heavily) The code for this was not working for a long time, but I
did correct most of it. You see, it is not, that I don't want those PS
operators (Why would I just have fixed the DPSXXimage: methods?), they
just don't get used, as they are to hard to be used correctly. 
One place where we would use the PS interface could be the displaying of
EPS files. For this format (and the same is true for SVG) we just need a
parser and than it would be just straight forward to do the drawing. I
really would like to find some time for this.

> to me that seems to indicate that we are doing five fairly simple types
> of operation
> with little in the way of complex interaction -
> 
> Window management operations
> 
> Complex curves etc using NSBezierPath
> 
> Images using a few operations
> 
> Text using NSStringDrawing
> 
> Simple lines and fills of areas
> 
This is just a special case of NSBezierPath.

> In which case, there really doesn't seem much postscript left anyway.

Not that correct. You did forget about the gstate handling. This is the
place where we should stick with the PostScript concept, but could try
to make things a bit easier to understand (I am not sure how to do it,
but I am very sure that only Adam would ever be able to fix a bug in
lockFocus).
Once again: We don't need a totally different interface, but we should
pack up the PostScript operation so that they are easy to use for an
application programmer and allow for fast implementations in different
backends.
Two places where I currently see room for improvement are the string
drawing (where we still don't see the best solution, but already know
that our current interface is not sufficient) and NSBezierPath where
operations could be a lot faster for any non-PostScript backend, if we
could transfer a pre-prepared path to the backend in one go.
An area of future extension could be the colour handling, as soon as we
try to do more than the simple colours we do now. (I really don't like
the Aqua interface, but if anybody wants to move in that direction, we
need those colours with patterns)

As you see, there is no simple divide (pro or con PostScript) in
GNUstep.

Cheers Fred