Re: Text drawing

[Fred Kiefer]

Alexander Malmberg wrote:
> Fred Kiefer wrote:
> > 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:

Sorry, to may have started another religiuos war about what belongs into 
GNUstep and what doesn't. Lets stop this right away. I was not going to 
prefer the PDF interface over the PS, what I wanted to suggest was to 
make the text drawing independent of the basic drawing model. The only 
operation we need in the front end is to draw a series of glyphs at a 
specific point. And this should be the interface we offer (what about 
GSShowGlyphsAt ?). Different backends would implement this differently. 
The PS printing would use PS command and have to clean the path at the 
end, wheras normal backend wont touch the path at all.


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

Removing valid and working PS interfaces should be no problem. At one 
point Adam throw away the whole stack handling, which I had fixed first. 
We don't need this for our normal drawing interface and so he was right 
to do this. If we ever need a PS interpreter, we will of course 
reimplement it there. But for the frontend-backend communication should 
restrict us even further and only offer what we need. Otherwise we again 
end up witht he current situations that backends only implement half the 
interface.

If anybody is really worried we could move the code currently in xlib up 
to GSGraphicsContext and simulate the operations as you suggested. But I 
see not much point in this.

Cheers
Fred