<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en" xmlns="http://www.w3.org/2005/Atom"><title>Recent changes to patches</title><link href="https://sourceforge.net/p/dclib/patches/" rel="alternate"/><link href="https://sourceforge.net/p/dclib/patches/feed.atom" rel="self"/><id>https://sourceforge.net/p/dclib/patches/</id><updated>2008-05-01T14:15:16Z</updated><subtitle>Recent changes to patches</subtitle><entry><title>unicode support in gui</title><link href="https://sourceforge.net/p/dclib/patches/6/" rel="alternate"/><published>2008-05-01T14:15:16Z</published><updated>2008-05-01T14:15:16Z</updated><author><name>Keita Mochizuki</name><uri>https://sourceforge.net/u/mocchi2008/</uri></author><id>https://sourceforge.net662bfeebe079e23e0a6159dcf0d18a41ab2fa031</id><summary type="html">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\).
</summary></entry><entry><title>Alt key support</title><link href="https://sourceforge.net/p/dclib/patches/5/" rel="alternate"/><published>2008-03-16T17:48:21Z</published><updated>2008-03-16T17:48:21Z</updated><author><name>Nils Labugt</name><uri>https://sourceforge.net/u/nlabugt/</uri></author><id>https://sourceforge.net5f9ebdbfd091254850fb6c5d44bde32c2c939888</id><summary type="html">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. 

</summary></entry><entry><title>Font patch</title><link href="https://sourceforge.net/p/dclib/patches/4/" rel="alternate"/><published>2007-11-21T22:11:54Z</published><updated>2007-11-21T22:11:54Z</updated><author><name>Nils Labugt</name><uri>https://sourceforge.net/u/nlabugt/</uri></author><id>https://sourceforge.net32465e9adf2f807640485890b0b177fe5dc92cfa</id><summary type="html">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\).



</summary></entry><entry><title>sockets_kernel - while(true)</title><link href="https://sourceforge.net/p/dclib/patches/3/" rel="alternate"/><published>2006-12-14T10:40:34Z</published><updated>2006-12-14T10:40:34Z</updated><author><name>Steven Van Ingelgem</name><uri>https://sourceforge.net/u/g00fy/</uri></author><id>https://sourceforge.net137847696a61656c603748381869f143bf0a4816</id><summary type="html">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,
Steven</summary></entry><entry><title>Even more warnings fixed ;)</title><link href="https://sourceforge.net/p/dclib/patches/2/" rel="alternate"/><published>2006-12-01T12:03:47Z</published><updated>2006-12-01T12:03:47Z</updated><author><name>Steven Van Ingelgem</name><uri>https://sourceforge.net/u/g00fy/</uri></author><id>https://sourceforge.net0791b9dc17768aa543036ae9245c9335179502aa</id><summary type="html">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,
Steven</summary></entry><entry><title>fixes some warnings</title><link href="https://sourceforge.net/p/dclib/patches/1/" rel="alternate"/><published>2006-06-02T19:30:47Z</published><updated>2006-06-02T19:30:47Z</updated><author><name>Steven Van Ingelgem</name><uri>https://sourceforge.net/u/g00fy/</uri></author><id>https://sourceforge.net7518461cce0eb137f90c9b2a1a26f6e68e6f882d</id><summary type="html">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 ;\)</summary></entry></feed>