The word wrapping routines now take so-called East-Asian width glyphs into account, since they should occupy two columns on most displays. Obviously, use of Asian character sets requires a client supporting UTF-8 encoding and binary-mode Telnet, as well as a font with the expected glyphs represented.
The latest release brings a refactored Telnet option negotiation stack, attempting to properly implement IETF RFC 1143. This is an outcropping of the recent additional supported Telnet options, as well as to simplify some upcoming improvements. More to come!
UTF-8 encoded input is now accepted from clients who negotiate the transmit binary Telnet option for sending, and UTF-8 output will be sent to any clients negotiating it for receiving (though clients should usually negotiate neither or both together). Most surveyed MUD clients have limited or no support at present, but this situation is slowly improving. In the meantime, rudimentary UTF-8/binary-mode Telnet documentation is being drafted to help simplify testing, and in hopes that this can serve as a reference implementation for other MUD clients and engines in the near future.
In preparation for an eventual Python 2.6/3.x transition, the mainline codebase has been reworked to be completely Unicode-clean. All embedded string constants are declared as Unicode data types now, and data streams from files and sockets are expected to be in either 7-bit ASCII or UTF-8 encoding. Any entry points for raw byte streams are clearly marked in the code so we can easily switch to using the byte data type in later Python versions.
Rather than keeping other improvements from going in while the new data format is under development, I’m treating that as a separate branch and continuing on the existing codebase in parallel for now. A new style guide has been added, and the code itself improved to meet it. Highlights: