gnustep-dev
[Top][All Lists]
Advanced

[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, 06 Jul 2004 03:03:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

Alexander Malmberg wrote:
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.


I found a way to get this implemented without a new method on the subclasses. The glyph conversion I had to use is horrible, but perhaps you have a cleaner idea for it. My suggestion would be a simple glyph generation API on the font info.

Fred




reply via email to

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