[Top][All Lists]

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

Re: State of initWithFocusedViewRect: on libart backend

From: Fred Kiefer
Subject: Re: State of initWithFocusedViewRect: on libart backend
Date: Tue, 29 Jun 2004 23:41:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

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

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.


reply via email to

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