[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of initWithFocusedViewRect: on libart backend

From: Alexander Malmberg
Subject: Re: State of initWithFocusedViewRect: on libart backend
Date: Mon, 05 Jul 2004 16:42:26 +0200

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.

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

0xd800 0xdf00

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


> and explain which one is correct?

Both. :) The destination encoding is different.

- Alexander Malmberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]