Re: displaying missing glyphs

[Leo Butler <leo.butler@umanitoba.ca>]

[-- Attachment #1: Type: text/plain, Size: 3929 bytes --]

<2QdxY4RzWzUUiLuE@potatochowder.com> writes:

> On 2021-04-12 at 13:45:20 -0500,
> Regarding "Re: displaying missing glyphs,"
> Leo Butler <leo.butler@umanitoba.ca> wrote:
>
>> <2QdxY4RzWzUUiLuE@potatochowder.com> writes:
>> 
>> >
>> > On 2021-04-12 at 12:08:08 -0500,
>> > Regarding "Re: displaying missing glyphs,"
>> > Leo Butler <leo.butler@umanitoba.ca> wrote:
>> >
>> >> Andreas Eder <a_eder_muc@web.de> writes:
>> >> 
>> >> > On Fr 09 Apr 2021 at 11:32, Leo Butler <leo.butler@umanitoba.ca> wrote:
>> >> >
>> >> >> I use `emacs -nw` inside of screen inside of uxterm. Unfortunately, many
>> >> >> unicode glyphs are not displayed correctly (although they are if I
>> >> >> attach the screen session in gnome-terminal, for example).
>> >> >>
>> >> >> In emacs/elisp, how might I override the default empty box to display
>> >> >> something more informative?
>> >> >
>> >> > The problem is - most likely - a font that is not unicode capable.
>> >> > If you set uxterm to ise the same font as gnome-terminal then it should
>> >> > work.
>> >> > The same combination (uxterm, screen and emacs) works perfectly well
>> >> > here.
>> >> 
>> >> Thanks for the suggestion. I have attached a marked-up screen shot of an
>> >> xterm (left) and gnome-terminal running `emacsclient -nw` and showing
>> >> the same buffer. You can see there is a noticeable clipping of some of
>> >> the characters in the xterm.
>> >> 
>> >> According to lsof, gnome-terminal is using
>> >> 
>> >>  /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
>> >> 
>> >> so the xterm has been run using
>> >> 
>> >> xterm -fa 'DejaVuSansMono' -fs 9
>> >> 
>> >> (and all font-related options are commented out in ~/.Xdefaults).
>> >> 
>> >> FWIW, this is on a debian testing system with XTERM_LOCALE=en_US.UTF-8.
>> >
>> > At startup time, both programs have to determine the size of a character
>> > cell.  They do so by applying some algorithm to the font(s) involved
>> > (the maximum width of all glyphs?  the average width of selected glyphs?
>> > something else?).  Evidently, xterm's algorithm doesn't account for all
>> > the glyphs, and ends up clipping some of them, whereas gnome-terminal
>> > has a different algorithm.
>> 
>> That seems like a reasonable answer, although, because I am ignorant of
>> all things font-related, I would have thought the font would have
>> contained this information.
>> 
>> >
>> > You clipped the xterm and gnome-terminal windows.  Are they the same
>> > size?
>> 
>> The two windows share 50% of the width of my screen. I used gimp to
>> select the whole screen, but I may have missed a few pixels on the
>> margins. Also, the WM (fluxbox) seems to create a 2-3 pixel-wide overlap
>> for reasons that escape me and this is consistent across applications.
>> 
>> >   Does the gnome-terminal contain more pixels (because it accounts
>> > for the wider glyphs)?
>> 
>> xwininfo shows the left window is 2 pixels wider than the right (800 v
>> 798). If I give each window 799 pixels, I still see the same behaviour.
>
> Okay, the windows are the same size in pixels, but look at the number of
> characters on a line.  The xterm window includes more characters, which
> means that the gnome-terminal window includes more pixels per character
> (the gnome-terminal window cuts your command off in the middle of the
> closing parenthesis of the call to format).

I don't think what you are saying is true. Open the file in gimp and cut
out the two lines you mention. You will see the character density is the
same (p2 of attachment).

I think that the attachment shows what Yuri said about gnome-terminal
vs. xterm's painting of the glyph is accurate (and gnome-terminal is
making an effort to scale the glyphs to fit into the allotted box,
whereas xterm does not seem to be.

>
> I don't think emacs has anything to do with it.

Yes, as I said, I was wondering how/if one can overcome this deficiency
using elisp.

Leo


[-- Attachment #2: xterm-clipping-2.pdf --]
[-- Type: application/pdf, Size: 213771 bytes --]