[libcaca] Re: updated patches for libcaca

[Sam Hocevar <sam@zoy.org>]

On Wed, Jun 27, 2007, Ben Wiley Sittler wrote:

> so far libcaca's idea of which characters are fullwidth is hardcoded,
> and does not vary by locale. however, in fact this data should vary by
> locale. libcaca should use wcwidth to determine when a character is
> fullwidth. in fact east asian (CJK) locales using double-byte
> encodings (GB18030, Shift_JIS, EUC-KR, etc.) have most characters
> outside of plain ASCII as fullwidth because this reflects the
> double-byte encoding of the non-ASCII characters. so if you use e.g.
> "kterm" on linux with LANG=japanese, you will see that many characters
> libcaca believes to be non-fullwidth (greek letters, for instance) are
> in fact fullwidth. wcwidth (after setlocale) reflects this.
> 
> so when approximating a unicode character using ASCII, if the unicode
> character might be fullwidth in some locales and would need something
> other than a blank space printed after it, i defined a cch2. i hope
> that someday libcaca will support the double-byte CJK locales, using
> the ncursesw backend at least (ncursesw already internally converts
> unicode to the locale character set and uses the locale's wcwidth data
> if you use the wide-character APIs instead of the byte APIs -- myman's
> internal ncursesw backend uses the wide-character APIs for this
> reason.)

   Okay, this makes perfect sense but it also means hell for canvas
exports or built-in characters. If I export a canvas where Λ or Γ are
half-width and are used to mean upside-down V or L, it'll look messed
up if I load it on a system where they are fullwidth. If I write a game
that uses ╬ ╦ ╣ in the code for graphics, I must constantly make sure
that I don't put them at odd coordinates in case they become fullwidth
in another locale...

   If you have any idea on how to solve this mess without making it too
difficult for the application writer, let me know ;-)

> in my opinion a lot more people would use it if the
> vertically-scrolling ttyvaders were released. having a horizontal game
> would be nice too, but why not release now the one that already works
> and is a good example of libcaca capabilities?

   You're probably right that a working game is needed. I just don't
feel motivated to work on the vertical scrolling one at the moment
because the code was really ugly and buggy and I feel it needs a rewrite
anyway.

-- 
Sam.
-- 
This is the libcaca mailing-list, see http://libcaca.zoy.org/
Trouble unsubscribing? Please contact <sam@zoy.org>
List archives are at http://libcaca.zoy.org/list/