https://bugzilla.novell.com/show_bug.cgi?id=360993 https://bugzilla.novell.com/show_bug.cgi?id=360993#c13 --- Comment #13 from Stanislav Brabec <sbrabec@suse.com> 2014-09-17 19:02:21 CEST --- Well. The keymap made sense with 8-bit locales limited to ISO-8859-* characters. There was not a way to output characters outside the 256 characters limit. The keymap is ugly hack to stick with ISO-8859-9 but be able to seemingly type €, but in fast still type ¤. The correct solution was provided later by introduction of ISO-8859-9E (/usr/share/i18n/charmaps/ISO-8859-9E.gz) that places € instead of ¤ in position 164. But locales in question (ku_TR, tr_CY, tr_TR) were never migrated from ISO-8859-9 to ISO-8859-9E (and now they are all deprecated in favor of UTF-8). Also lat9w-16 font is a font intended for use in 8-bit locales and 8-bit terminals with this hack. It contains UNICODE mapping table, but this table is apparently incorrect (i. e. hacky): Using psftools, I see: // Character 164 Bitmap: -------- \ ---###-- \ --##--#- \ -##----- \ -##----- \ ######-- \ -##----- \ ######-- \ -##----- \ -##----- \ --##--#- \ ---###-- \ -------- \ -------- \ -------- \ -------- Unicode: [000000a4];[000020ac]; The Unicode map should map character 164 to [000020ac]: U+20AC EURO SIGN and not to [000000a4]: U+00A4 CURRENCY SIGN. Mapping it to both hides the hack in the keymap mapping ¤ to 0xA4 and expecting €. All these hacks worked in 8-bit locales, as the output interpretation was encoding-dependent, and when interpreted in ISO-8859-9E, there was an € character. But with UTF-8, these hacks stopped to work: UTF-8 depends on exact character names in keymaps and exact Unicode maps in fonts (psfu) or external consoletrans files. The correct fix would be a bit complex: - kbd: Fix the keymap - kbd: Fix all lat9w fonts embedded Unicode maps. - kbd: Write 8859-9(e|w)_to_uni.trans map - glibc: Generate locales the map is intended for (ku_TR, tr_CY, tr_TR) with ISO-8859-9E instead of ISO-8859-9. - glib: ditto in /etc/profile.d/zzz-glib2.* - Probably also apache and other packages still supporting 8-bit fallback would need fix. I am afraid that it will not happen any time soon. In my quick review few years ago, nearly all embedded maps in psfu fonts in embedded package are inferior, full of bugs, and need to be fixed. Such work would require days of work. We will only maintain setups for YaST. As long as they are correct, we WONTFIX other bugs. However you are free to fix all of issues above and send the fix upstream. It will appear in the next SUSE version. Note: There are no easy to use psf fonts editors. Most of the fonts there come from age of MS-DOS, were created by MS-DOS editors and never modified later (except of format conversion). psftools is far the best tool I was able to find. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.