gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Text drawing


From: Alexander Malmberg
Subject: Re: Text drawing
Date: Sun, 02 Nov 2003 02:17:51 +0100

Fred Kiefer wrote:
> The clean up of the text layout has been on my list for long now. As I
> still dont find time to do it, here are two simple ideas for some of the
> problems, where I would like to hear comments on:
> 
> 1) The layout manager uses the following lines to set a text colour when
>   non has been specified:
> 
> DPSsetgray(ctxt, 0.0);
> DPSsetalpha(ctxt, 1.0);
> 
> This should of course be replaced by [[NSColor textColor] set] to
> respect the colour scheme of the user.

Thanks! I've fixed this.

> Or if we really mind the speed
> here by caching this colour and using the cached value.

I cache it in one call now, but not across calls. The value can change
at runtime, so you need to be careful if you do cache it, and I don't
think this will be a significant bottleneck.

> 2) Then there is quite a mess in the direct string drawing. We have a
> whole set of different methods the front end could call. I think that we
> should remove everything apart from GSShowGlyphs, GSShowText and
> DPSshow. The difference between the last one and the other two will be
> that this works together with the path, wheras the first ones use the
> text position. The text drawing code in NSLayoutManager would than be:
> 
> GSSetTextPosition(ctxt, gbuf_point);
> GSShowGlyphs(ctxt, gbuf, gbuf_len);
> 
> And GSShowGlyphs must of course be changed in all backends to use the
> textCtm and to leave the path untouched.

I agree that cleanups here would be nice, but I disagree about the how.
:)

The pdf-ish text position/text ctm stuff should be removed. It doesn't
add any new functionality, it doesn't map cleanly to postscript (which
we need to be able to print), and it makes a mess of the semantics of
text drawing. Since nobody knows how the pdf/ps mix is supposed to work
there's no documentation, no implementation (they're all straight
postscript), and no use of it.

With hindsight, I think it was a mistake to add it. Anyway, there's no
harm in removing it now, which leaves us with:

DPSshow - postscript 'show', really only suited for ascii text

GSShowGlyphs - postscript 'glyphshow', but accepts several glyphs for
efficiency (obviously, backends can implement it any way they like as
long as the result of a call are identical to the result of the sequence
of glyphshow:s)

This also gives us well-defined (documented: ps manual :) semantics, and
it matches the current de facto situation.

> All the other DPSXXXshow methods should be removed. I don't think
> anybody has been using them for years now.

I'm a bit split over this. I'm not really happy about removing valid
postscript operators. OTOH, they have the same problems as 'show' wrt
character sets, and I don't think they're used anywhere. -xlib seems to
be the only backend that implements them.

Since you can do the same things with sequences of show/glyphshow, I
think it'd be ok to remove them.

I can probably do this work during next week.

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]