https://bugzilla.novell.com/show_bug.cgi?id=849342 https://bugzilla.novell.com/show_bug.cgi?id=849342#c0 Summary: mlterm cannot show Japanese characters as default Classification: openSUSE Product: openSUSE 13.1 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: tiwai@suse.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- mlterm cannot show any Japanese characters as default unless you set up the font manually. The culprit is the recent change in the upstream code to query the fixed font at first. https://bitbucket.org/arakiken/mlterm/commits/b55a26f18f5f63804040b8d3cbcbf4... This changes not only using the fixed font but also checking only "c" spacing. Unfortunately most of biwidth fonts (e.g. efont-unicode) don't give c but only p spacing. Thus, with this change, these fonts won't hit any longer but a wrong font is picked up in the end. A possible fix is either to fall back to efont for biwidth fonts just like doing for gnu-unifont. But this is ugly. Another fix is to probe other spacing variants for biwidth unicode fonts. This works, but if gnu-unifont is in the font path, gnu-unifont will be picked up even if it doesn't match with the actual pixel size by X server side resizing. This results in badly shaped glyphs. Though, gnu-unifont-bitmap-fonts is installed in /usr/share/fonts/uni/ and this path isn't included in the default font path, thus the problem won't happen as default. If any user changes the font path, it's user's responsibility, so we don't have to care so much, too. -- 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.