Re: "Jaguar" additions

[BALATON Zoltan]

Hello,

On Tue, 27 Aug 2002, Adam Fedor wrote:
> Creating a colorspace in GNUstep would be as simple as creating a
> dictionary with the correct keys and values (I've attached an updated
> file that has those filled in). Then pass that dictionary to
> -GSSetFillColorspace: or -GSSetStrokeColorspace:

OK, so the backend has to keep track of existing color spaces to avoid
creating a new one everytime a color space is set on a context. When one
of the above methods is called the backend would have to look up if an
existing color space with the same parameters already exists and set that
on the context. This implementation is different than would be needed for
the Quartz API, where the user passes a reference and the above method
just sets that on the context.

> I've added more documentation to NSGraphicsContext.m (you have to run

Thanks.

> BALATON Zoltan wrote:
> > Me either, see above. It seems the current tendency is to implement
> > graphics features in the gui however they should be implemented in the
> > backend and allow backends to implement them as they see fit. This applies
> > to at least NSAffineTransform, NSBezierPath, NSColor, NSFont,
> > NSGraphicsState, probably more. (They could probably be moved to gsc.)
>
> Those classes are implemented that way because that is how the need to
> be implemented in order to fit the API and interact with other objects.

I didn't mean to change the API (we want to be compatible with the
OpenStep API), but the gui now also contains concrete implementations
which in my view should belong to the backend.

> There HAS to be a translations between objects and
> C-structures/backend-structures SOMEWHERE.

Yes, and this should be in the backend. Afterall the task of the backends
is to translate objects to lower level implementations to provide a pdf
and/or postscript imaging model on which the gui is built. Let's
categorise currently existing backends: the two extremes are gsc based
backends (xlib and winlib) on one end and gslib on the other.

The gslib backend uses ghostscript which has implementations for almost
everything needed for both imaging models (in C). A backend built on gslib
has to map ghostscript functions and structures to GNUstep objects and
methods. In other words it implements GNUstep methods using ghostscript.
For NSGraphicsContext this is supported by the backend interface very
well, this part of the gslib backend is also very simple.

Gsc based backends on the other hand take a different route. They
reimplement the pdf imaging model in ObjC (in gsc) without using any
external, already existing implementations and provide a lower level
interface (than the backend interface) to map this onto native platform
facilities (which is done in xlib and winlib). (Ghostscript also has a
corresponding lower level interface: the driver interface.)

Backart is somewhere in between in this respect. It is mostly a gsc based
backend in that is it uses the implementations from gsc for most things.
But it is similar to the gslib backend in that it uses the libart
implementations for paths (and possibly other things) and freetype for
fonts. For these it also needs to do a mapping between gsc paths and
libart paths and NSFonts and freetype fonts.

The problem is that the line between gsc and the gui (the backend
interface) is not well defined and the gui now contains some
implementations that should rather be in the backend.

One concrete example is how to implement font support in gslib. Currently
GraphicsContext is mapped to a gs_state structure. The method to set a
font on the context is passed an NSFont object. I have to map this to a
gs_font structure, since that is what ghostscript expects. Ghostscript has
a complete implementation of postscript fonts with all the functions
needed to implement NSFont and NSFontManager. But the NSFont is opaque and
mostly implemented in the gui. It delegates some of its functionality to
the backend via GSFontInfo, but ghostscript provides a higher level
implementation thus it is not a good match for the gslib backend. I see
two ways to circumvent this: one is to put a gs_font in GSFontInfo and try
to synchronise it to NSFont but this is error prone, the other is to
subclass NSFont in the backend and reimplement it using ghostscript, but
the superclass still had wrong implementations which the gui might try to
use. The solution seems to be to remove all implementations of graphics
related things from the gui and do them in the backend.

> However, since we've already
> implemented NSAffineTransform, NSBezierPath, etc. it makes sense to use
> those implementations in our graphics implementation, and just do the
> translation to the "native" format in the backend.

There's nothing wrong with these implementations and they should be used
if there is no other implementation in the backend. But if the backend has
a different implementation of the same thing then there could be a
conflict.

I've just saw this potential problem while trying to fit font handling in
the gslib backend so I thought I'd bring it up here to discuss it.
Probably the problem does not exists, I'm just missing something. I hope
others who know the gui and backend better can help to find a way to
implement font handling in the gslib backend and resolve the problem with
the backend interface if there is one.

Regards,
BALATON Zoltan