Re: "Jaguar" additions

[BALATON Zoltan]

On Mon, 26 Aug 2002, Alexander Malmberg wrote:
> There are methods for setting the colorspace (-GSSetFillColorspace: and
> -GSSetStrokeColorspace:), but they're neither documented nor
> implemented.

Furthermore the methods to actually create color spaces are missing. (Same
for imagerefs.) Without this it is not possible to implement these
methods.

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

Exactly this is the way how ghostscript's pdf interpreter does it, and how
I could also implement it in the gslib backend. (But you need to keep
track of the colorspace too.) For which colorspace/color to use in
operators you may want to look at lib/pdf_ops.ps in ghostscript, look for
set{fill,stroke}state (for DPScompositerect this may not help, at least I
dont know which pdf operator corresponds to it).

> > Also alpha values assigned to colors in Quartz are confusing me
> > currently.
>
> In what way?

In that I don't see where does it fit in ghostscript or pdf, because I
don't know pdf enough. Colors in ghostscript have no associated alpha
values, but the gstate has several trancparency properties, namely shape
and opacity alpha plus a blend mode (probably others exist). As far as I
understand these are there to support the pdf alpha model, but I don't yet
understand it fully.

> The problem is that other backends have no interest in ghostscript's
> structures.

I agree, but other backends might want to use their own structures so they
might run into the same problem.  (E.g. libart and freetype also have
their own representations of things as structures such as X11 or Windows.)

> We need a common interface towards the AppKit, and the
> backends will have to map that onto whatever they want to use
> internally.

Yes, but IMO this interface should allow backends to use their own
representations of graphics things (most importantly contexts, paths,
color spaces, fonts). For contexts this is already possible, for fonts it
is partially possible and I don't know about color spaces.

> Thus, we might as well use objects (almost, I'm not entirely
> convinced yet :).

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

> Implementing the Quartz c interface directly? It is an option, but I'm
> not sure it'd be a good idea.

Me either, that's why I've asked. It would probably be easier with gslib,
but it would be harder to integrate it into GNUstep afterwards.

> Doesn't it rely on CoreFoundation (or
> whatever that foundation-in-c things is called)?

Only at a few irrelevant places, see the commented out parts containing
CG* in opal.h. These could be circumvented.

Regards,
BALATON Zoltan