Re: 2-bytes character display ready ?

[Richard Frith-Macdonald]

On Tuesday, February 19, 2002, at 05:13 AM, Richard Frith-Macdonald 
wrote:

> On Monday, February 18, 2002, at 10:37 PM, Fred Kiefer wrote:
>
> > Yen-Ju Chen wrote:
> >
> > >   I asked this question several months ago,
> > >   and when I check the xgps source code recently,
> > >   I found in XGFont.m, two "FIXME" say it might be able to support 
> > > 2-bytes
> > > character.
> > >   I would like to know is GNUstep ready for 2-bytes character 
> > > display ?
> > >   If it can be done by only modifing the xgps backend,
> > >   I would like to try it out with my limited ability.
> > >   As least it is easy for me to test the 2-bytes display.
> >
> >
> > Sorry, we still don't provide the full Unicode text information from 
> > the front end to the back end. Actually the GNUstep developers at the 
> > FOSDEM have just been discussing this last weekend. And somehow I once 
> > again failed to make my point. So for the next time, we have to live 
> > with the PostScript interface between these two modules, which only 
> > allows for ASCII sized characters.
> > Just to repeat this: The problem is more in the interface of the back 
> > end than in the backed itself.
>
> I guess you failed to make your point because we misunderstood you.
> Perhaps you misunderstand the interface?
> I disagree that there is a (functional) problem with the interface, but
> there is obviously a problem of understanding just how it is supposed 
> to work.
>
> Getting a copy of the 'PostScript reference manual' (red book) would 
> be a
> good idea.
>
> I'll try to go into some detail in my next reply to Yen-Ju

APOLOGY!

I just checked the source code, and found that the DPS functions we have,
which are really just convenience functions for the more general DPS 
client
interface, do not do what we need.

In PostScript, a 'string' is explicitly defined as an array of integers, 
each in
the range 0 to 255 ie an array of bytes.

The DPSshow() function is a convenience for simple nul terminated C 
strings ...
and can't pass the full set of postscript strings we need to use.

For support of large character sets, we have to be able to send a true 
postscript
string, which is something that DPSshow can't do.  Using the xdps 
backend this
is not a problem, but we don't have the full dps support in the xgps 
backend.

I think the simplest fix is to an a new function (just as you suggested) 
to
implement a 'show' operation using a byte array.  Under the xdps backend 
this
would simply wrap the postscript code needed.