Re: "Jaguar" additions

[Alexander Malmberg]

> The differences between Quartz and postscript are mostly in colorspace,
> alpha and text handling.

There are methods for setting the colorspace (-GSSetFillColorspace: and
-GSSetStrokeColorspace:), but they're neither documented nor
implemented.

> The separate fill and stroke color spaces are not
> supported in ghostscript at the library level, the pdf interpreter in gs
> (implemented in postscript) stores them in variables and sets the
> appropriate one before executing drawing or filling operators. This could
> be done in C similarly.

In back-art this is no problem; I just keep track of separate stroke and
fill colors and use the right one. In some cases it isn't obvious which
one to use, though (eg. DPScompositerect; currently I use the fill color
for it).

[snip]
> Also alpha values assigned to colors in Quartz are confusing me
> currently.

In what way?

> > Since we aren't limited to C compatibility, we can use objects for
> > passing information, so the interface is much simpler than Quartz
> 
> Actually to me it is not simpler. To the contrary, since ghostscript has
> it's own notions of most data types (such as AffineTransform, BezierPath,
> ColorSpace, Font, Point, Rect, see the beginning of the comparison) I have
> to convert GNUstep objects to ghostscript structures, because ghostscript
> expects to get gs_matrix and gs_font and not NSAffineTransform or NSFont.
> This is a problem since GNUstep code uses the objects while ghostscript
> uses the structures so the two will get out of sync. (Especially if the
> implementation in GNUstep and ghostscript are different.) A better way
> would be to implement the objects using the structures but I don't see how
> to do this with the current backend interface.

The problem is that other backends have no interest in ghostscript's
structures. We need a common interface towards the AppKit, and the
backends will have to map that onto whatever they want to use
internally. Thus, we might as well use objects (almost, I'm not entirely
convinced yet :).

> > (although we should build a Quartz interface to NSGraphicsContext some
> > time).
> 
> With gslib at least the easier way currently seems to be going the other
> way, that is first building a C interface and then use it in
> NSGraphicsContext (and possibly NSFont and NSColor as well which is
> currently missing from the backend interface).

Implementing the Quartz c interface directly? It is an option, but I'm
not sure it'd be a good idea. Doesn't it rely on CoreFoundation (or
whatever that foundation-in-c things is called)?


Some comments on quartz_gs:

> typedef struct {
>   float m11, m12, m21, m22, tx, ty;
> } NSAffineTransformStruct;

Often, this is represented as an NSAffineTransform object in gs.

> ?NSStringEncoding

GSFontInfo's mostCompatibleStringEncoding is probably the closest.
However, if we're going to switch to using pango to do text drawing,
this will probably change.

- Alexander Malmberg