|
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
[Prev in Thread] | Current Thread | [Next in Thread] |