Re: State of initWithFocusedViewRect: on libart backend

[Alexander Malmberg]

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

I was assuming that for consistency, the restriction would be applied to
all *show operators, and that would break a few users of DPSshow. I
guess we could apply it only to the new operators, but that would make
them rather restricted; I'd just as well leave them unimplemented in
that case.

Anyway, I could do a quick implementation of a -DPSshow: (const char
*)string length: (int)length; operator if someone did the gsc parts.

[snip]
> >>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?

int theCharacter=0x10000; ?

(Question doesn't make much sense, though. Did you mean 16-bit value?)

> Could you give an
> example of a UTF8 sequence where your code would yield a different
> result as Richards

Character 0x10300, "OLD ITALIC LETTER A", is encoded in utf8 as:

0xf0 0x90 0x8c 0x80

The code in Unicode.m will convert this to utf16, in which it is encoded
as:

0xd800 0xdf00

while my code will convert it to the actual character number (in a
32-bit int; this encoding is called ucs4):

0x10300

> and explain which one is correct?

Both. :) The destination encoding is different.

- Alexander Malmberg