Author: Alexander E. Patrakov
Date: 2003-11-06
License: Public Domain
Synopsis: Using UTF-8 Locales in [B] LFS
Description:
THIS HINT Explains What Should Be Changed in The LFS and BLFS INSTRUCTIONS
Crest at the time of this Writing in Order To Use Locales Su_ru.utf-8.
Prerequisites: LFS 5.1-Pre1 or Later, Good Knowledge of C
Conflicts: Compressed Manual Pages
*** Note ***
This hint is not maintained by the author.
***
Changelog:
2003-11-06: Initial Submission
2004-02-25: Added Some BLFS PACKAGES
Hint:
Important Information
Don't Follow this Hint Unless to FIX BROKEN THINGS! I NEVER
Had A Full BLFS Install, And of Course Because of this Some Packages That
Are Broken In Utf-8 Locales May Well Be Missing from this Hint.
Also, please don't ask Support Questions related to this hint on mailing lists
Hosted on Linuxfromscratch.org (And Of Course Don't Provide Support Yoursel)
If You can't Answer The Questions at the end of the hint.
Also Note That While Our GOAL IS To Move To The International UTF-8 Encoding,
We Have to Disable InternationalizationAnation Completely in Some Older Applications.
So this hint really becomes an antihint: we gain Nothing Except Compatibility
WITH BLEDING-EDGE Redhat-Like Distries, and DEFAC
Lost ... lost what weely aiming to get --- Internationalization.
Once Again, Don't Follow this Hint Blindly.
Big Warning: You will probably has to conve control all your documents.
Part 1. Introduction
1. SINGLE-BYTE AND DOUBLE-BYTE ENCODINGS AND UTF-8: What's Wrong
Most Eropean Languages Have a Relatively Short Alphabet (Less Than 40
Characters. This Makes it Possible to create a represent the
CHARACTERS OF THAT (Both Upper-Case and Lower-Case), English Alphabet, Digits and Punctuation With a single byte. The result is known as a single-byte
Encoding. An Example of Suh Encoding IS Koi8-r, Commonly Used In Russia. All
SINGLE-BYTE ENCODINGS ARE ASCII-Compatible In The Sense That Characters
Representable in Ascii Are Also Reperestable in There Encodings and Have the
Same Code. They area Also Reverse-Ascii-Compatible In The Sense That Every Byte
With the value less Than 0x7f represents The Same Character As It Does in
ASCII. Current LFS AND BLFS WORK Well with Such EncoDings.
This Approach Doesn't Work with Asian Languages Such as Chinese, Japanese and
Korean (Denoted together as cjk further in this hint). They Have More Than 256
Different Characters, Because Single Characters Repesent Syllables and Even
Words. SO Called Double-byte Encodings Are Used with these languages. They
REPRESENT ENGLISH Letters, Digits and Punctuation with Single Bytes Equal To
ASCII REPRESENTATION OF THOSE Characters. To represent native cjk character,
Two-byte sequences are used. Such Encodings Are Called Double-Byte. AN
Example is GB2312, Used in China. Since CJK Characters Are TWICE AS WIDE AS
English Ones in monospaced font, The "on-screen" width of a string encoded with
Such Methods Is Directly ProPorctional To The Number Of Bytes in It (There IS
One Exception: Any Two-byte Sequence Starting with 0x8e Byte in Euc-JP Takes AS
Much space as an english letter. LFS and BLFS DON 'T Work Well with Asian
Languages and Double-byte Encodings Because of Two Reasons:
1) IT Is Impossible to Display Double-Width Characters on a Linux Console (Even
ON A Framebuffer Console) WITHOUT ADDITIONAL Programs That Are Not in The Book.installation of E.g. ENCON CORRECTS THIS.
2) Some Assumptions That Work with Single-byte Encodings Fail with Double-Byte
Ones. First, Some Double-Byte Encodings Are Not Reverse-Ascii-Compatible: a
Byte with value less Than 0x7f can be each Either an ascii-representable character
OR A Second Byte of A Two-byte Sequence. Second, Correctly Finding The N-TH
Character in a string is a complex task because thing some character occupy one
Byte, and some characters are represented by two-byte sequences. Software That
Makes Bad Assal Patched or Not Installed At ALL.
Today there is a nesed to encode multilingual texts. E.G., Foreign Clients of
Companies don't want their name to be decorated up to unreconzable stat
a chain of multiple transliterations. Since all Single-byte and double-byte
ENCODINGS Are Capable of Reprresenting Characters of At Most TWO ALPHABETS
(ENGLISH National), There Is a Need for a New Character Set to ENCODE
Multilingual Texts. Such Character Set EXISTS AND IS NAMED Unicode.
UTF-8 IS A Method of Repruthing Unicode Text with a stream of
8-bit bytes. The resulting stream isboth ascii-compatible and
Reverse-ascii-compatible. A Single Character Can Occypy from 1 to 4 Bytes. Many
Current Distributions of Linux Configure Locales Using To UTF-8 Character
Encoding by Default. This Doesn't Work with (b) LFS for the Same Reasons As with
Double-byte encodings. however,
1) There is no framebuffer-based Terminal That Is Capable of Displaying THE
Full Range of Unicode Characters (if One Doesn't Count Debian-Specific Bterm
From The "BOGL" Package, Bogl = Ben's Own Graphics Library) .fortunately, IT IS Not Needed in Most Cases. Linux Console IS Capable of
Displaying Latin (Including Accented), Greek, Arabian and Cyrillic
Characters TOGETHER EVEN WITHOUT FRAMEBUFFER. Also, xterm Works Just Fine.
2) There is one more assumption That Breaks with UTF-8. The Relation of
ON-Screen Width of A String to the Number of Bytes in it is very complex.
That's why e.g. Midnight Commander Works with double-byte encodings, but
Doesn't Work with UTF-8.
3) MANY PACKAGES in UTF-8 Locale Fail to Provide Compatibility with Older
Docuvents Saved in Traditional Single-byte OR Double-byte Encoding.
Part 1. LFS PACKAGES
Suggested Changes to the Installation Instructions. INSTRUCTIONS
The Following Packages Should Be Configured Differently in Chapter 6:
- NCURSES
- Vim
- man
1A. Modified ncurses Installation Instructions INSTRUCTIONS
First Of All, You Need NCurses 5.4. Get IT from
http://ftp.gnu.org/gnu/ncurses/ncurses-5.4.tar.gz
The New NCurses Version Has Experimental Support for Wide Characters.
According to the output of ./configure --help, it is actid by passing
The --enable-widec argument to ./configure. The resulting libraries are
Binary-incompatible with "Normal" ncurses and therefore a letter "w" IS
Appended Automatic or To Their Names: Libncurssw.so.4.4. for Compatibility
WITH Precompiled Commercial Applications, WE WILL Install Two Versions Of
NCURSES.
Now We are ready to install the non-wide-character version of ncurses, almost
By the book:
./configure --prefix = / usr --with-shared --without-debug
Make
Make Install
THISTALLS /USR/LIB/LIBNCURS.SO.5.4. WE WILL MOVE IT TO / LIB LIB LIB LIB LITER.
THEN INSTALL A WIDE-CHARACTER-ENABED VERSION: MAKE DISTCLEAN
./configure --prefix = / usr --with-shared --without-debug --enable-widec
Make
Make Install
This Installs /usR/LIB/Libncurssw.so.4.4 and related libraries.
Move Important Libraries TO / LIB AND CORRECT PERMISSIONS:
CHMOD 755 /usR/LIB/*.5.4
Chmod 644 /usr/lib/libncurses *.a
MV /USR/LIB/LIBNCURS.SO.5* / LIB
MV /USR/LIB/LIBNCURSW.SO.5* / LIB
Make the symbolic links:
ln -sf ../../lib/libncursesw.so.4 /usr/lib/libncurses.so
ln -sf libncurses.so /usr/lib/libcurses.so
ln -sf ../../lib/libncurssw.so.5 /usr/lib/libncurssw.so
ln -sf libncursesw.so /usr/lib/libcursesw.so
Note The First Command. Now All Applications Trying to Link At Compile Time
Against -Lncurses Will ActualLink to the Wide-Character Version,
/LIB/LIBNCURSW.SO.5. THIS WORKS, BECAUSE THE TWO LIBRARIES ARE
Source-Compatible. At Runtime, The Linker Will Happily Resolve The Dependency
Upon libncurssw.so.5. and for precompiled Commercial Applications That
Depend On The Ordinary Version of ncurses there is /lib/libncurses.so.5.
1b. Modified Vim Instructions
For Vim to Work Correctly in Double-byte Encodings and in UTF-8, THE
--enable-multibye switch has to be added to the ./configure command line. Note
That it is not necessary in blfs since --with-features = (more than normal)
Implies this.
Echo '#define sys_vimrc_file "/ etc / vimrc" >> src / feature.h
Echo '#define sys_gvimrc_file "/ etc / gvimrc" >> src / feature.h
./configure --prefix = / usr --enable-multibyte
Make
Make Install
Ln -s Vim / USR / BIN / VI
Vim Is Able to Edit Files in Arbitrary Encodings if you use utf-8-based local.
E.g. to read the file price.txt That Is Known To BE in CP1251 Encoding, Type :: E ENC = CP1251 Price.txt
IT Will Be Automatically Converted. To save the file in koi8-r encoding under
The name price.koi, Type:
: w enc = koi8-r price.koi
Vim Is Even Able to Automaticly Detect The Character Set of the File
Being Read under Some Conditions. this Works Because Real Texts in Most
SINGLE-byte and double-byte encodings contain sequences of bytes That Are not NOT
Valid in UTF-8.
THIS CAPABILITY NEEDS to Be Configured. To do so, create the file / etc / vimrc
With the folowing contents (Replace Koi8-r with the name of a single-byte OR OR)
Double-byte encoding what is most often used in your country:
Begin / etc / vimrc
Set Nocompatible
SET BS = 2
Set FileEncodings = UCS-BOM, UTF-8, KOI8-R
"END / ETC / VIMRC
For more information, read /usr/share/vim/vim62/doc/mbyte.txt
1c. Modified Man Instructions
Since Man Internationalization Does Not Work At All in Utf-8 Locales (The
Messages Are Still Output in Single-byte or Double-byte EncoDings, Appearing
AS LINES OF Unreadable Squares on the screen) and Because Russian Messages Are
Improperly translated (and offensive!) We will disable nls. this will not
Prevent You from Viewing Manual Pages in Your Native Language. It Just Means
That Messages Like "What MANUAL PAGE Do You Want?" Will Remain Untranslated.
Install the "man" package with the followiing commands:
Patch -np1 -i ../man- Patch -np1 -i ../man- Patch -np1 -i ../man- DEFS = "- DNONLS" ./configure -default -confdir = / etc lang all Make Make Install Now we have to decide what to do with manual pages in Your native language.they are provided with the corresponding packages in the single-byte OR Double-byte Encoding, But Not in Utf-8. Therefore, They Won't display protroperly. There is the qu. THE FIRST Solution Is To Store Them in The Single-byte OR Double-byte Encoding, I. As They Come with the Corresponding package, And Convert Theim Into UTF-8 On the fly. to do this, search for the line in /etc/man.conf That Starts with "Pager". Replace It with something like the folowing: PAGER / USR / BIN / ICONV -C -F KOI8-R | / USR / BIN / LESS -ISR (Replace Koi8-r with your 8-bit or double-byte eNCoding). Note That change Does not hurt you if you late switch back to the us Usual ENCODING: ICONV WILL Be a no-op. unfortunately, this Doesn't Work Well with Graphical Man Page Viewers like Yelp (from gnome-2.4) or konqueror, Since They Just Ignore T "Pager" Variable in /etc/man.conf (if the read /etc/man.conf at all) and Assume That Manual Pages Are Stored in The Character Set of the Current Locale. The Second Solution Would Be To Convert Manual Pages To UTF-8. Unfortunately, I Had no success with this. Redhat provides Some Patches for groff-1.18.1. I Tried to Convert All Manual Pages Into UTF-8 and Changd Man.conf to Have The Line # Wrong! NROFF / USR / BIN / ICONV -C -T KOI8-R | / usr / bin / nroff -tlatin1 -mandoc | / usr / bin / iconv -c -f koi8-r This Didn't Work Well Because Some Manual Pages Contain Just .so filename And Don't Display Properly. IN FACT, THE * ROFF Specification Says That The Input Must Be in ISO8859-1 Encoding, there is no way to typeseet Anything Except Latin and Greek According To The Specification, And All Localized Manual Pages (Even in The Single-bytecyrillic Koi8-R Encoding!) Are Really a Hack and Violate The Specification. 2. Setting Up UTF-8 Based Locale and Environment Variables Some UTF-8 Locales (E.G. SE_NO.UTF-8) Are Installed During The Make localedata / install-locales Step While Installing Glibc. But Most of UTF-8 Locales Must Be CREATED Manually, E.g .: LocaleDef -c-xi ru_ru -f utf-8 ru_ru.utf-8 The role of the --c switch is to continue the creation of the logale even thing WARNINGS Are Issued. after the creation of the locale, it is needed to tell Applications to use it. all this is required is to set some environment Variables. An easy "sol) is to add this to your / etc / profile: # WRONG !!! Export lc_all = ru_ru.utf-8 Export lang = ru_ru.utf-8 This "Solution" is WRONG BECAUSE THESE VARIABLES WILL BE AVAILABLE TO Processes Started from your login shell, But Will Not Be available to the readline Library That The shell Usess. The Readline Library Uses this information E.g. to DETERMINE How Many Bytes to Remove from The Input Buffer (Must Be One UTF-8 Character) and how much character Cells To Erase On The Screen (Again, ONE Full Character) IF you press backss or delete key. Yes, if You _Type_ EXPORT LC_ALL = Ru_ru.utf-8 in The Login Shell, Then IT Will Pass this setting to the readline library. But this doesn't work in the shell STARTUP Files. this is a bug in bash. so the correct lc_all variable must becomes Already in the environment gen the login shell starts. IF One Adds The Above LC_All and Lang Variables INTO / ETC / ENVIRONMENT, IT WILL Work for login shells Started by The "login" Program, But Will Not Work for SHELLS Started by "su" or "sshd" Programs. this approach also requires you Toplace these Variables Into / etc / profile solby from KDE (The "Startkde" Script From Kde 3.2.0 Sources / etc / profile). Another approach is to make the login shell set the correct locale variables And Reexecute Itself. To Accompilsh this, add the folowing snippet at the Very Beginning of Your / etc / profile: IF ["x $ lc_all" = "x"] THEN Export lc_all = ru_ru.utf-8 Export lang = ru_ru.utf-8 IF (Echo $ - | GREP -Q I) THEN EXEC -A "$ 0" / bin / bash "$ @" Fi Fi The $ - check is there saltimes / etc / profile is soliometer Sourced by Other Scripts this runs. Such shells don't need to be bel Reexecuted, Since you don't want to replace a script that source / etc / profile With an instance of / bin / bash called with the Same Parameters as the script. Of course, you will have to replace ru_ru Above with something more ApproPriate. If you are useless xdm, you alsowant to incrude the folowing lines inclu the Beginning Of / etc / x11 / xdm / xsession: [-r / etc / profile] &&. / etc / profile [-r $ homen / .bash_profile] &&. $ homen / .bash_profile Consult the documentation of other display managers for the means to set the Environment in The Started Session. 3. Setting Up Linux Console We will modify the /etc/rc.d/init.d/loadKeys script. #! / bin / bash # Begin $ rc_base / init.d / loadingkeys - loadingKeys Script # Based on loadKeys Script from LFS-3.1 and Earlier. # RETTEN BY Geekmans - Gerard@linuxfromscratch.org # Modified for utf-8 locales by Alexander E. Patrakov - Semzx@newmail.ru Source / etc / sysconfig / rc Source $ rc_functionsecho -n "setting screen font ..." For console in / dev / tty [1-6] DO ( SetFont SetFont Latrcyrheb-16 ) <$ console> $ console 2> & 1 DONE Evaluate_RetVal echo -n "loading keymap ..." KBD_MODE -U LoadKeys Ru1 2> / DEV / NULL && DUMPKEYS -C KOI8-R | LoadKeys - UNICODE Evaluate_RetVal # End $ rc_base / init.d / loadingkeys Some Comments Concerning this Script. 1) The EMPTY "SetFont" Command Works Around A bug in 2.6 kernels. 2) We don't switch the console output to utf-8 here. We will do what in / ETC / ISSUE (The Idea Is Stolom "redhat-style-logon" hint). THIS IS Necessary Because OtherWise this Switching Will Affect Only the first console. As an alternative, you can write a "for" loop here sending Virtual consoles. 3) The KBD Package Does Not Provide Ready-to-Use Keymaps for UTF-8 Locales, Except for ukrainian one. first, we load the now-wrong ru1 keymap (the numeric Character Codes There Are Valid Only for Koi8-R Character Set, THEN We DUMP IT Replacing Numeric Codes with Human-Readable Descriptions of Characters (E.g. "cyrillic_small_letter_e"). The resulting keymap is usable in UTF-8 MODE, SO We load it with loadKeys --unicode. Let's create / etc / issue: Echo -e '/ 033 [2J / 033 [F / 033% GWELCOME to Linux from scratch / n'> / etc / issu The meaning of the escape sequences: Set Up Screen Font and keyboard now, if you don't want to reboot: /etc/rc.d/init.d/loadKeys THEN KILL All Agetty Processes for Them To Reread / etc / Issue: Killall Agetty4. conclusion From Your Next Login, You Will Use UTF-8 BASED LOCALE, with All ITS Benefits And drawbacks. KNown Bugs: - The Caps Lock Key Does Not Work On Linux Console for National Characters. The guilty package is kbd. - Some pack Don't Display Line Drawing Characters in UTF-8 Mode on Linux Console. this is a bug in the package. See Alsa Semselves. See Alsa Semselves For more detailed discustion. Part 2. BLFS PACKAGES GNUPG The Package Itself is Internationalized Well and Supports UTF-8 OUT OF THE BOX. Unfortunately, Some Applications (E.G. ENIGMAIL) Assume That The Output of GPG Is in ISO8859-1. for Applications That Cannot Be Fixed Easily, Create T FOLLOWING SCRIPT: #! / bin / sh EXPORT LC_ALL = C Export lang = c EXEC / USR / BIN / GPG "$ @" Save it as / usr / bin / gpg-nolocale, Give It The "Executable" Bit and Configure . 2. Emacs I don't use emacs at all, but your comments are wellcome. Don't expect Any console-based Editor Except Vim, Emacs and Yudit To Work in UTF-8 Locale. 3. Slang Get the patch http://www.linuxfromscratch.org/patches/downloads/slang/slang-1.4.9-UTF8.PATCH Install Slang Using The Following Instruments: Patch -np1 -i ../lang-1.4.9-UTF8.PATCH ./configure --prefix = / usr Make cflags = "- o2-pipe -dutf8" Make Install Make cflags = "- O2 -PIPE-DUTF8" ELF_CFLAGS = "- O2 -PIPE-DUTF8" ELF Make Install-Elf Make Install-Links Chmod 755 /usr/lib/libslang.so.1.4.9 WARNING: You Should Pass -dutf-8 in CFLAGS TO All Applications That Depend On Slang. 4. Aspell TO BE DONE. 5. gpm GPM Cannot Cut / Paste Non-Ascii Characters. It is really a limited of Linuxconsole. You Can Google for a kernel patch named Unicode_copypaste_2.4.19.patch.gz But I Would Recommend Against It. I Had Crashs and Repeatable Kernel Panics WITH IT. 6. Zip / unzip If You Put a file with non-ascii characters in its name into the archive, you Will be unable to get this name correly under window. 7. Midnight Commander First, Install Slang. Then, Get The Patch http://www.linuxfromscratch.org/patches/downloads/mc/mc-4.6.0-utf8.patch Install Midnight Commander with The Following Instructions: Patch -np1 -i ../mc-4.6.0-utf8.patch Cflags = "- O2 -PIPE-DUTF8" ./configure / --prefix = / usr --with-screen = SLANG / --what-else-you want, e.g. --with-vfs --with-samba --enable-charset --without-ext2undel / --with-configdir = / etc / samba --with-codePagedir = / usr / share / samba / codepages Make Make Install Unfortunately, this Patch Is Not Sufficient. In particular, IT IS IMPOSSIBLE TO View and Edit Files Containing Non-Ascii Characters Using The Internal Viewer and Editor. Configure Midnight Commander To Use An External Editor, E.G. Vim. 8. W3M You NEED W3M-M17N, NOT JUST A Bare W3m. Unfortunately, W3M-M17N-0.4.2 Does Not EXIST YET. 9. MUTT, PINE I don't use the the on all, but debian has a patch for mutt. Your Comments Are Welcome. 10. GTK -1.2.10 This Package's default style files in / etc / gtk don't work in UTF-8 locales. Changing "Koi8-R" to "ISO10646-1" FONTS IN / Etc/gtk/gtkrc.ru fixes the problem WITH IMPROPER FONTS for Russians. BEWARE THAT KDE Also Sets Gtk Styles (in ~ / .kde / share / config / gtkrc and ~ / .gtkrc), So these Files Also May Need Some MANUAL EDITING. 11. Lesstif This Package Does Not Support Unicode Well. 12. KDemultiMedia The Players show id3 tags with national characters improperly. 13. Yelp The Problems With Manual Pages Have Already Been Mentioned in Man Section. 14. ALSA Alsamixer 1.0.2 Won't show The line drawing character on Linux Console in LINUX IN UTF-8 Mode. This is a bug in alsamixer. The problem is there KNOW WHETHER THE Linux Console Is in UTF-8 Mode or Not Do That, NCurses Checks The Current Locale Setting (in The Order: lc_all, lc_cType, lang). Also, IT Has to Compute How Many Cells a Given Character Occupies. This Requires a Valid LC_CTYPE SETTING. But this Means That a Program That Links to NCurses Must Call SetLocale (lc_cType, ") Before INITSCR (). this patch fixes the issesue in alsamixer http://www.linuxfromscratch.org/patches/downloads/alsa-utils/alsa-utils-1.0.2-locale.patch After Reading The Text Above and Looking At The Alsamixer Patch, You Should Be Able To FIX This Kind of a Problem with Other Packages. please send Patches to patches@linuxfromscratch.org. Don't send a patch for the "lxdialog" Program That Comes with the kernel Sources and is buy during "make menuconfig", Since this Will Break Question 2 in The Quiz Below and I Will No longer Be Able To Check WHETHERS Are Ready to follow this hint. 15. XMMS This package will not show id3 tags protily out of the box, because theies USUALLY IN THE WINDOWSSH SINGLE-BYTE OR DOUBLE-BYTE ENCODING AND NOT IN UTF-8. The Patch from http://rusxmms.sourceforge.net/ Helps. 16. DILLO This package does not support unicode. 17. xsane The gtk -1.2.10 Version is affected by a bug in gtk style support And does Not Work Properly Even in ru_ru.koi8r local. To Work AroundThe Problem, Don't Build The Gimp Plugin --- Then Xsane Will Link Against GTK2. 18. XPDF Since THIS PACKAGE Depends on Lesstif, The Support of Utf-8 in The GUI IS Rather Poor. E.G., The FileNames in The FileSelector show improperly. but THE NON-GUI TOOL, PSTOTEXT, WORKS FLAWLESSLY AND CAN Extract Text In The UTF-8 Encoding from pdf files. 19. A2PS This package does not support unicode. 20. TEX To use utf-8 as an input encoding with tex, you shouth download the folowing Package: http://www.unruh.de/dniq/latex/unicode/unicode.tgz Just unpack it inTo / usr / share / texmf / tex, Remove All Files Except UCS / *. STY, UCS / *. DEF, UCS / DATA / * And the run mktexlsr. Then you will be able to write / usepackage [uTF-8] {INPUTENC} In The Document Preamble, But I Doubt That Anyone else Will Be Able To TEX Your documents. If you want someone else to beable to extract text in UTF-8 Encoding from Your PDF Files Generated by PdfTex or Dvipdfm, You Should Also Install The "cm-super" font package from ctan. Part 3. Conclusions Probably you understand from reading the Above That UTF-8 Causes more Trouble Than Merit. if you followed this hint, I hope That I Didn't Damage Your System Irreversibly. Please post your deviations and report Other broker package Patrakov@UMS.USU.ru Appendix A. Quiz You Should Follow The Hint Only if you know all the answer. 1) The Non-Wide Character Version of NCURSES 5.4 Uses Poor-Man Line-Drawing Characters on Linux Console in UTF-8 Mode. What Other Terminal Type is affected by this? Where (Which File and Line) Is The Check? Where is the the basen of code That Substitutes these Poor-Man Line-Drawng Characters INSTEAD of Those Which Came from The TerminFodatabase? Where does NCURS 5.4 Check The Current Locale? 2) Linux kernel build process uses the "lxdialog" Program During the "Make MenuConfig" Step. Unfortunately, LXDialog Has The Same Bug AS Alsamixer (see the hint). Can you make a patch for lxdialog yourself?
