Re: "Jaguar" additions

[BALATON Zoltan]

Hello,

I have attached for reference the header file with the definitions
extracted from the Quartz documentation. It is named opal.h (wonder why,
see http://mineral.galleries.com/minerals/mineralo/opal/opal.htm)

On Thu, 22 Aug 2002, Adam Fedor wrote:
> Actually, I've already added all the methods in NSGraphicsContext that
> would be needed to implement Quartz, I just haven't documented them (bad
> Adam :-)) I'll try to do that soon - generally they're all the methods
> that start with GS.

Are you sure that's the complete set? I made a comparison between Quartz,
the current GNUstep backend interface and ghostscript. The results are in
the attached file named quartz-gs. In that file definitions are grouped as
follows:

CG* (Quartz feature)
DPS*, NS*, GS* (GNUstep feature)
gs* (Ghostscript feature)

A ? in place of either one means I was unable to find matching feature in
the given interface.

The comparison shows that most of the Quartz functionality have
corresponding DPS and ghostscript functionality. Thus ghostscript
functions map quite well to Quartz functions, but the GS functions not
always match Quartz functionality. The missing GS functions are mostly in
colorspace handling which seems to be missing from GNUstep currently. On
the other hand there are GS functions for which no corresponding Quartz
(or in some cases DPS) functionality seem to exist.

The differences between Quartz and postscript are mostly in colorspace,
alpha and text handling. 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. The text differences could be emulated in the same
way, though the TextMatrix feature does not seem to be in gslib and the
missing font handling is still a problem. The different alpha handling and
pdf blending modes are supported by gslib, but I couldn't yet figure out
how. Also alpha values assigned to colors in Quartz are confusing me
currently.

> 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.

> (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).

I would be interested in feedback from other developers as well.

Regards,
BALATON Zoltan

PS: Any news about the NEWS gateway? Since Aug 9. the gatewaying of the
mailing lists to newsgroups are broken.

opal.h.gz
Description: opal.h

quartz-gs.gz
Description: quartz-gs.gz