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.

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...

Is this still an issue?

yes - given the same font and glyphs

Yup, still an issue.

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).

Not fixed. I've just verified it's still happening on xterm version 288.

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).

Created attachment 73905 [details]
Script to showcase the problem

This script should make reproducing the problem trivial.

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.

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...).

(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

Still an issue, some 6 years after reporting it.

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.

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.

The issues with bitmap fonts won't go away.
xterm can display those characters using TrueType fonts.