Re: State of initWithFocusedViewRect: on libart backend

[Fred Kiefer]

Alexander Malmberg wrote:
> Fred Kiefer wrote:
> > While I was looking at the code in backart, I had some totally unrelated
> > ideas. What about unifying the unmaintained string drawing code, that is
> > all the other string showing Postscript commands apart from DPSshow? We
> > could just move them up to GSGState and implement them via a
> > DPSshowString:length: primitive. Not that anybody is using this methods
> > now, but at least we wont have parts of them scattered everywhere in the
> > backends.
>
>
> You mean by decomposing the calls into sequences of DPSshow (or
> equivalent) and DPSrmove? Could be done, but the method would have to be
> aware of all encodings a backend could use to figure out character
> boundaries. We could go further and prohibit multi-byte encodings here,
> but that would break a few (very few, I think, but at least two) apps.
> (But note that -gui never uses these operators.)

Yes exactly, that was my idea. The problem you are mentioning for 
different encodings, where we should handle multi byte characters is 
currently only a theoretical one. The xlib backend supports only single 
byte strings here and the art backend doesnt even implement these 
methods. So how could this break exisiting applications? We might as 
well just drop the code here, but there may be a few old OpenStep 
applications using it.

> > And there my next question came up (I shouldn't be reading this much
> > code): What is backart doing in [FTFontInfo
> > drawString:at::to:::::color::::transform:] to convert from UTF8 to
> > Unicode? Or more specific, in which regard is this conversion different
> > from the one implemented in GSToUnicode in Unicode.m?
>
>
> It's inline and handles characters above 0xffff directly instead of
> going via utf16.

The later is actually the part I don't understand. How is it possible to 
pack a character > 0xFFFF into a 32-bit value again? Could you give an 
example of a UTF8 sequence where your code would yield a different 
result as Richards and explain which one is correct?
I just read a bit about UTF-8, UTF-16 and USC-2 and still I don't see 
how this could work.

Fred