https://sourceforge.net/p/dclib/patches/Recent changes to patchesenThu, 01 May 2008 14:15:16 -0000https://sourceforge.net/p/dclib/patches/6/Hi Davis, I have modified this library so that gui widgets may deal with Japanese font. The main points of modifying are below. \(1\) creating set\_text \(or set\_name\) overload methods, which has one of three argument \(std::string, std::wstring or dlib::ustring\). these methods regard std::string as environmentally-dependent multi-byte string, and std::wstring as UTF16\(when sizeof\(wchar\_t\)==2\) or UTF32\(when sizeof\(wchar\_t\)==4\). \(2\) creating the functions which convert encoding string in new file unicode.cpp. -convert\_mbstring\_to\_utf32 \(which use mbstowcs\) -convert\_utf32\_to\_mbstring \(which use wcstombs\) -convert\_mbstring\_to\_wstring \(which use mbstowcs\) -convert\_wstring\_to\_mbstring \(which use wcstowcs\) -convert\_wstring\_to\_utf32 -convert\_utf32\_to\_wstring \(3\) changing the member of std::string in each widgets into dlib::ustring. \(4\) changing the return value type of text\(\) \(or name\(\)\) into dlib::ustring due to \(3\). \(5\) creating the font class which using TextOut \(in Win32\) or XwcDrawString \(in X11\). Keita MochizukiThu, 01 May 2008 14:15:16 -0000https://sourceforge.net662bfeebe079e23e0a6159dcf0d18a41ab2fa031https://sourceforge.net/p/dclib/patches/5/Patch for Alt-key support. No idea if Windows implementation compiles. Needs testing on Mac. I didn't change on\_keydown because of backwards compatibility, but added a new method instead. Nils LabugtSun, 16 Mar 2008 17:48:21 -0000https://sourceforge.net5f9ebdbfd091254850fb6c5d44bde32c2c939888https://sourceforge.net/p/dclib/patches/4/I just put the new class in a file together with a test program, ready for you to cut and paste, but diff file for font.h and font.cpp. The font files I used for testing can be found at: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html \(The demo text file in the tarball was downloaded from there as well.\) The BDF spec can be found here: http://asitis.org/files/font\_specs/bdf\_spec.zip Issues: -I have not implemented UTF8 versions of compute\_cursor\_rect or compute\_cursor\_pos. -I have not tested everything. compute\_size\_u8 hasn't been tested at all. \- font::is\_combining\_char is neither pretty nor very fast. One alternative is to use a table \(uses some extra memory\), another is to encode it into the letter objects \(uses some as well\). -I didn't discover mbrtowc until I had written my own UTF8 converter, but it would pull in the locale.h header, and the prototype says it takes a char\* which seems a bit inconvenient when one is starting out with a string object anyway. mbrtowc would have some advantages of course... -I loaded the Korean font, and it consisted of almost 28000 glyphs and 2063768 points. The letter class uses long ints internally for x and y, which is 64 bits on a LP64 platform. 16 bytes times 2063768 points is about 33MB, which is a bit much IMHO. Even 16MB on an 32 bit system is a problem for embedded devices. -Another issue is what type to use as Unicode characters. A quote from version 5.0 of the Unicode standard, page 155: "The width of wchar\_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar\_t for storing Unicode text. The wchar\_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers. However, programmers who want a UTF-16 implementation can use a macro or typedef \(for example, UNICHAR\) that can be compiled as unsigned short or wchar\_t depending on the target compiler and platform. Other programmers who want a UTF-32 implementation can use a macro or typedef that might be compiled as unsigned int or wchar\_t, depending on the target compiler and platform. This choice enables correct compilation on different platforms and compilers." The signedness of wchar\_t is left to the implementation as well. "unsigned wchar\_t" compiles on gcc, but looking at the \(draft\) standard I'm not sure that it should. char32\_t would be ideal, but AFAIK it will not appear in C++ until C++09. I wasn't sure what to do, so I just created a typedef to unsigned int. Maybe I should have used a different typedef externally and internally? Or \#define? u8\_to\_u32 would need to be modified to work with 16 bit \(including its name\). Nils LabugtWed, 21 Nov 2007 22:11:54 -0000https://sourceforge.net32465e9adf2f807640485890b0b177fe5dc92cfahttps://sourceforge.net/p/dclib/patches/3/sockets\sockets\_kernel\_1.cpp: read: This is wrapped in a while\(true\), but in fact it's not needed at all... Because any line of execution will return immediately. In \_2.cpp it's needed because it can be interrupted. Greetz, StevenSteven Van IngelgemThu, 14 Dec 2006 10:40:34 -0000https://sourceforge.net137847696a61656c603748381869f143bf0a4816https://sourceforge.net/p/dclib/patches/2/Can you check this patches if it's the same as what it should do? I changed it because VS2005 was outputting some warnings on those lines. Greetz, StevenSteven Van IngelgemFri, 01 Dec 2006 12:03:47 -0000https://sourceforge.net0791b9dc17768aa543036ae9245c9335179502aahttps://sourceforge.net/p/dclib/patches/1/G++ spawns some warnings about things inside the constructor being assigned a value before other things... Here is the patch for the things I use. Prolly you can find a lot more in the library ;\)Steven Van IngelgemFri, 02 Jun 2006 19:30:47 -0000https://sourceforge.net7518461cce0eb137f90c9b2a1a26f6e68e6f882d