[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libcaca] Re: updated patches for libcaca
hi, i just updated to your newest version (revision 1123) and it works
well. you cleaned up and rewrote my patches, and the code is much
cleaner now, thank you!
however, there is a problem in the x11 driver. two characters had
their data reversed. a patch is attached.
* caca/driver_x11: fixed data for left and right tee
the patch is also at:
http://zoehep.xent.com/~bsittler/libcaca-trunk-1123.diff
i also notice that the slang driver prints incorrect output for
fullwidth characters. for instance, 'Ｈｅｌｌｏ' becomes 'HHeelloo', but
'H e l l o ' is a much better approximation. maybe there should be a
cucul_utf32_to_ascii-like function that converts to a string of ASCII
characters instead...
and finally, it looks like the ncurses changes are not merged yet. let
me know if you would like me to clean that up more.
thanks,
-ben
On 6/27/07, Ben Wiley Sittler <bsittler@gmail.com> wrote:
On 6/27/07, Sam Hocevar <sam@zoy.org> wrote:
> On Tue, Jun 26, 2007, Ben Wiley Sittler wrote:
[snip]
> > * caca/driver_slang.c: when the libslang does not support utf-8
> > output, use ASCII approximations for vt-100 and cp437 graphics
> > characters
>
> In this patch (and in the ncurses one) there are plenty of cch2
> assignations even for characters that are not fullwidth (for instance
> 0x00002591). Can you explain that a bit more?
in that particular case (U+2591) cch2 is not needed, since (AFAIK) no
double-byte charsets included it. however, here is an explanation of
why i did that for all characters that might need right-extension
during halfwidth approximation of fullwidth display:
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.)
> > also, there is an updated MyMan to better support the new features.
> > same URL as the old version:
> >
> > http://zoehep.xent.com/~bsittler/myman-0.7pre1.tar.gz
>
> Excellent! You seem to be the first external developer ever to really
> use libcaca for anything else than its bitmap->text capabilities.
hopefully the first of many :)
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?
-ben
Index: caca/driver_x11.c
===================================================================
--- caca/driver_x11.c (revision 1123)
+++ caca/driver_x11.c (working copy)
@@ -583,9 +583,9 @@
0x00, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x00,
/* 0x2510 - 0x251f: â?? . . . â?? . . . â?? . . . â?? . . . */
0x14, 0x00, 0x00, 0x00, 0x41, 0x00, 0x00, 0x00,
- 0x44, 0x00, 0x00, 0x00, 0x54, 0x00, 0x00, 0x00,
+ 0x44, 0x00, 0x00, 0x00, 0x51, 0x00, 0x00, 0x00,
/* 0x2520 - 0x252f: . . . . â?¤ . . . . . . . â?¬ . . . */
- 0x00, 0x00, 0x00, 0x00, 0x51, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x15, 0x00, 0x00, 0x00,
/* 0x2530 - 0x253f: . . . . â?´ . . . . . . . â?¼ . . . */
0x00, 0x00, 0x00, 0x00, 0x45, 0x00, 0x00, 0x00,