Re: "Jaguar" additions

[Adam Fedor]

BALATON Zoltan wrote:
> 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 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.

> 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

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.

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

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

P.S. On a somewhat related note, I've had a tremendous amount of trouble 
integrating pango into gui. Pango does a great job at displaying text, 
but is absolutely terrible at editting text (i.e. changing the 
structures that contain the layout info).


--
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.