Re: "Jaguar" additions

[BALATON Zoltan]

On Wed, 28 Aug 2002, Adam Fedor wrote:
> I see your point here. I could add methods to track references to the
> colorspaces. In fact I could change things so they all took or returned
> opaque types, so that the backend could override them to return it's own
> particular colorspace object.
>
> Although now I think it might be better if I just added a key to the
> colorspace dictionary that allowed the backend to store it's own data
> necessary to construct the colorspace. We could even do that for other
> objects, like Fonts.

I like the opaque types that the backend can override idea better. This
fits the gslib backend more. A GSColorSpace object or something similar
could be used for this. Then the gslib backend could implement it using
gs_color_space and gs_cspace* functions and the gsc backend could use the
implementation that is now in NSColor.

> Well, this is a potential stumbling block to my second idea above.
> However, I'm leary about subclassing gui classes in the backend. We've
> tried that before (although with ALL gui classes, not just graphic ones)
> and it got out of hand trying to keep both front and backend classes
> up-to-date. I'd like to keep the interface between the front and backend
> as simple as possible.

I didn't suggest to allow subclassing for all gui classes, but for
graphics related ones it should probably be allowed. Keeping the interface
simple is also an iportant point though. If we can avoid code duplication
it can be manageable. Code duplication can probably be avoided by putting
implementations in the backend like those now in gsc where it can be
reused by several backends (or backend drivers in ghostscript terms).

> On the other hand, NSFont is one class that never got fully transfered
> to the front-end, and perhaps it's because it's complex enough that it

It might not just be complexity but rather the fact that systems on which
backends must run have very different notions of this object on their own.
Also the interfaces different systems provide are at different levels.

> doesn't make sense. Perhaps we need to rewrite NSFont so it can be
> subclassed more directly in the backend. The other graphics objects are
> probably simple enough that we don't need to do that.

Two other possible candidates in my opinion are NSColor and NSBezierPath.
They might not be too complex but systems on which backends are to
be implemented likely have their own implementations of these objects.

> But, just to complicate things, if we ever wanted to go with a really
> good text handling package like Pango, we'd need to subclass a bunch of
> gui classes (including NSFont) to handle pango structures as well. There

I don't know pango very much but it seems to me that it provides even
higher level facilities than gslib. It has implementations for things in
NSAttributedString, NSLayoutManager NSFont and the NSText cluster. Thus it
is at a higher level than the backend interface so chances are that it
does not fit below there. If this is the case then it is similar to my
problem with gslib.

> could be quite a conflict there (e.g. there's currently no
> pango-ghostscript backend, although there is a pango-freetype backend).

As pango and ghostscript are roughly at the same level a pango-ghostscript
backend probably does not make sense. Ghostscript has it's own notion of
text layout and fonts that matches the postscript and pdf model (e.g.
ghostscript supports composite fonts for the font fallback that was
discussed in other threads). Pango might implement a different model so it
might be harder to bend it enough to fit into GNUstep.

Thank you for the valuable comments,
BALATON Zoltan