Bug 15979 - kanji not shown when bold.
Summary: kanji not shown when bold.
Status: REOPENED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xterm (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Thomas E. Dickey
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-16 22:20 UTC by Roc Vallès Domènech
Modified: 2014-05-13 01:03 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the behaviour (14.59 KB, image/png)
2008-05-16 22:20 UTC, Roc Vallès Domènech
no flags Details
Script to showcase the problem (140 bytes, text/plain)
2013-01-30 06:39 UTC, Roc Vallès Domènech
no flags Details
screenshot of xterm-bug-15979.sh on xterm-288 (18.03 KB, image/png)
2013-01-30 06:42 UTC, Roc Vallès Domènech
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roc Vallès Domènech 2008-05-16 22:20:18 UTC
Created attachment 16592 [details]
Screenshot of the behaviour

When text is bold, japanese kanji characters will be displayed as squares.

Screenshot provided, making the case where the problem happens clear.

xterm version is 235, though the bug has been around for a long time.
Comment 1 Thomas E. Dickey 2009-07-29 17:51:57 UTC
It depends on the font - a text-file which creates the screen
would be useful (to help reproduce the problem).  For instance,
looking at glyphs in the Unicode range 0x4e00 - 0x9fff (which
one source implies is the corresponding range for Kanji - a
unified Han character set), the fonts that I normally use with
uxterm do not display any usable glyphs.  I get better results
with 18x18ja

-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1

For that font, xterm+ncursesw are able to display bold and
non-bold versions of the same glyphs.  Unifont

-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1

works better - though there are some display issues which do
not match the description in this report.

The reason that knowing the fonts (-fn, -fb, -fw, -fwb) is
important is that if the glyphs are (according to wcwidth)
double-width, xterm will choose a different font than given
by -fn, etc.  The likely reason for the bold characters
showing as boxes is that the bold font which is given by the
font server may not have the same glyphs as the normal font.
Comment 2 Roc Vallès Domènech 2011-02-07 16:29:49 UTC
Still happening with current versions.

If drawing bold text isn't possible but drawing non-bold is, non-bold should be drawn instead of those boxes...
Comment 3 Jeremy Huddleston Sequoia 2011-10-06 09:45:50 UTC
Is this still an issue?
Comment 4 Thomas E. Dickey 2011-10-07 01:33:13 UTC
yes - given the same font and glyphs
Comment 5 Roc Vallès Domènech 2011-10-15 17:17:19 UTC
Yup, still an issue.
Comment 6 Thomas E. Dickey 2013-01-05 13:35:50 UTC
http://invisible-island.net/xterm/xterm.log.html#xterm_282
improve rendering for the case when a Unicode character is absent in the bold font but present in the normal font by temporarily falling back to the normal font (Debian #359006, Debian #408666).
Comment 7 Roc Vallès Domènech 2013-01-19 05:58:11 UTC
Not fixed. I've just verified it's still happening on xterm version 288.
Comment 8 Thomas E. Dickey 2013-01-20 19:01:40 UTC
thanks.  On noting the reopen, I thought perhaps I had not
implemented the change for the -fw/-fwb options, but reading
the code see that I did.  It would be helpful to have a copy
of the test-data used for the screenshot (as well as a hint
of the fonts used, in case those are not the default set used
for uxterm).
Comment 9 Roc Vallès Domènech 2013-01-30 06:39:03 UTC
Created attachment 73905 [details]
Script to showcase the problem

This script should make reproducing the problem trivial.
Comment 10 Roc Vallès Domènech 2013-01-30 06:42:18 UTC
Created attachment 73906 [details]
screenshot of xterm-bug-15979.sh on xterm-288

This showcases the problem with the directory generated by the xterm-bug-15979 script on xterm-288 from Gentoo, with its default configuration, no ~/.Xresources file used.
Comment 11 Thomas E. Dickey 2013-02-02 01:33:59 UTC
For the given example, I'm not seeing (using xterm's normal UTF-8 fonts)
anything that points to "bold".  The CJK characters show properly with/without
color in the "Large" setting, but as boxes in the other sizes - because
neither the bold/normal glyphs are in those fonts

(I'm reading this report as different from fontsets - something
that I might do in the next iteration of xterm, depends on time
and which fires I'm putting out...).
Comment 12 Roc Vallès Domènech 2013-02-02 06:49:37 UTC
(In reply to comment #11)
> For the given example, I'm not seeing (using xterm's normal UTF-8 fonts)
> anything that points to "bold".  The CJK characters show properly
> with/without
> color in the "Large" setting, but as boxes in the other sizes - because
> neither the bold/normal glyphs are in those fonts
> 
> (I'm reading this report as different from fontsets - something
> that I might do in the next iteration of xterm, depends on time
> and which fires I'm putting out...).

Perhaps you'll find this useful to reproduce it with ls:

reimu ~ # /usr/bin/dircolors
LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:';
export LS_COLORS
Comment 13 Roc Vallès Domènech 2014-05-12 05:14:03 UTC
Still an issue, some 6 years after reporting it.
Comment 14 Thomas E. Dickey 2014-05-13 00:44:18 UTC
Actually, I did add logic in xterm to do this.

However, some of the fonts do not provide correct information
to tell which cells are missing.  I checked the default font
used by uxterm for example, and can see this is the case for
the example which you gave.
Comment 15 Thomas E. Dickey 2014-05-13 01:03:08 UTC
However, I see one case where it might be possible to improve it,
and am testing that change, to see if there are side-effects.


bug/show.html.tmpl processed on Mar 29, 2017 at 19:07:45.
(provided by the Example extension).