Re: Text drawing

[BALATON Zoltan]

On Sun, 2 Nov 2003, Alexander Malmberg wrote:
> 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

I agree.

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

They could be easily implemented using the DPS functions for compatibility
with CoreGraphics later as Opal/FusedSilica if needed.

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

This is not true in postscript. See section "Fonts/Character Encoding" in
PLRM. Using different encodings it can support multiple encoding schemes
including multibyte encodings using CID-keyed fonts, but the latter is
quite complicated, so practically it is probably limited to single byte
encodings. This encoding support however is probably not implemented in
the gsc backend. One possible solution would to support encodings in the
backend as this could be more efficient than using glyphshow.

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

Concerning character sets see above. These methods may be useful if font
handling is moved to the backend as I have suggeted before by allowing the
backend to provide an implementation of NSFont and removing GSFontInfo.
This is another possible cleanup that would probably allow more efficient
string drawing entirely implemented in the backend using platform specific
font support mechanisms without having to keep information in the gui in
sync with platform specific font data in back.

Regards,
BALATON Zoltan