| Summary: | updated xft patch for fluxbox-0.9.6.ebuild | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mamoru KOMACHI (RETIRED) <usata> |
| Component: | New packages | Assignee: | Commonbox Team <commonbox> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | enhancement | CC: | ciaran.mccreesh, ktdeeter, nakano |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
diff to fluxbox-0.9.6.ebuild
fluxbox-0.9.6-xft.patch new patch |
||
|
Description
Mamoru KOMACHI (RETIRED)
2003-12-17 09:11:41 UTC
Created attachment 22360 [details, diff]
diff to fluxbox-0.9.6.ebuild
Created attachment 22362 [details, diff]
fluxbox-0.9.6-xft.patch
I've spoken to fluxgen (one of the fluxbox authors) regarding this patch. He asks: This patch forces the use of XftDrawStringUtf8 even though one didn't specify UTF-8 in any LC_* variable. What's the reason to not use locale_to_utf8 in the first if-statement and use it where m_utf8mode == false... Additional comments from fluxgen: Please use new/delete instead of C function malloc... I'm asking to the patch's author if he would rewrite it. If he won't, I'll do that. (nakano, who gave me the modified patch, said he will help me in doing so) Any progress here? Sorry for the delay. nakano knows the author of the patch personally and he contacted him. nakano wrote that the author said he would rewrite it during new year holidays. nakano is on vacation until Thursday, so I'll ask him when he returns. Sounds good, thanks for the update. Created attachment 23640 [details, diff]
new patch
new version from patch author.
Summary of Changes:
* changed malloc/free to new/delete
* moved locale_to_utf8 to FbTk/StringUtil.cc
* changes to FbTk/XftFontImp.cc are same as before
As for the XftDrawStringUtf8 issue, here is a translated response from the author.
<start author's comment>
In the original FbTk/XftFontImp.cc around line 94 is the following code:
#ifdef HAVE_XFT_UTF8_STRING
if (m_utf8mode) {
XftDrawStringUtf8(draw,
&xftcolor,
m_xftfont,
x, y,
(XftChar8 *)(text), len);
} else
#endif // HAVE_XFT_UTF8_STRING
{
XftDrawString8(draw,
&xftcolor,
m_xftfont,
x, y,
(XftChar8 *)(text), len);
}
When HAVE_XFT_UTF8_STRING is true and a UTF-8 locale is set (m_utf8mode == true) then the text is a utf-8 string so XftDrawStringUtf8() works fine.
However, when m_utf8mode == false, problems arise, because the code assumes non-utf-8 text to be a single byte encoding. In the case of encodings like euc-jp, where characters are represented using two bytes each, XDrawString8 fails to render correctly.
It might be possibel to use XftDrawString16 in this case, but even in euc-jp, the lower ascii characters are represented using one byte only, so there is an extra step to figure out if characters are represented using 8 bits or 16 bits.
Instead of doing all this work, the patch just converts everything to utf-8 (which is a relatively well defined operation) and uses XftDrawStringUtf8
<end author's comment>
As for the second part of the comment, i think the new patch uses locale_to_utf8 only where m_utf8mode == false.
< fluxgen> tseng: could you make a comment... < tseng> sure. < fluxgen> tseng: that the utf8 == false doesn't work with swedish letters < fluxgen> tseng: somethings wrong with the utf-8 conversion Could one of you give this a look? Thanks. < fluxgen> tseng: ah it gets EILSEQ add that to the comment I'm guessing you know what this means, I'm just the middleman ;) I wrote an email to confirm with the patch author, however, from my quick look at it, it seems to just be using iconv for hte conversion so my uneducated guess would be that something is wrong with the iconv setup of whoever is testing it.. but I'll write more once the author gets back to me. I've recieved confirmation from the patch author that an EILSEQ means that there is something wrong with the input to the function. Either iconv is not set up right, the locale is not specified correctly, or something in that vein. from "man iconv" EILSEQ An invalid multibyte sequence has been encountered in the input. If you guys are still working on this, please try and get in touch with fluxgen@fluxbox.org, or in #fluxbox on the same name. Adding this to Fluxbox is his call, im not a fan of patching up Gentoo-only sources when the author seems to be willing to work with you. Keep me updated here. TIA |