Re: [dev] st bug report and feature request

From: <u-st-jfpt_AT_aetey.se>
Date: Sat, 24 Sep 2011 21:12:50 +0200

On Sat, Sep 24, 2011 at 01:19:47PM -0400, Bryan Bennett wrote:
> For the second bug, An example may help. I ran into
> (what I believe to be) the same bug a few months ago,
> but assumed it was a problem with the font rather than
> with st. (I had been making modifications to the font for
> a while and assumed I'd done something wrong.) I
> made a screenshot of the issue, which you can see here:
> http://ompldr.org/vYWljbA

Looking at your screenshot I can neither confirm nor exclude that
it is the same issue.

I get a very wide window, the cursor being displaced to the right about
twice, in relation to the end of the typed command line,
the echoed characters appear both next to the previous character
and somewhat to the left of the cursor, the latter instance disappears
at focus change (moving the mouse out of the window in my case).

So it looks definitely like wrong positioning of the cursor and wrong
display. A redraw on events makes the picture look more "correct" in the
left part of the window with the phantom copy at the cursor disappearing,
leaving though a very wide unused margin to the right. When the picture
contains double width chacraters, they are not placed in a grid but
apparently misplaced. A line full of such characters takes the whole width.

In my eyes it looks like an issue arising when the terminal picks a font with
some characters of double width.

The appearance of the font and the distortions vary when I vary the font
selection string (by recompilation).

Having said this, I want to emphasize that core fonts have some issues
which can not be overcome by programming, not even very clever.

If nothing else, many of them look ugly and nor the developer nor the
user can influence the choice which an unknown X11 server will make
(which even can refuse to provide a font of desired properties).

Please consider using client side fonts, it does not have to mean extra
complexity nor size. At any rate, supporting exactly one client side
font is easy. As the st code looks today, there is only one font (and its
bold counterpart). I guess even oversimplified boldness (say doubling
the active pixels) of a nice font will look better than the bold monsters
which core fonts can randomly offer :)

By random I mean that moving to another screen leads to unpredictable
change of the font chosen by the same template.

Regards,
Rune
Received on Sat Sep 24 2011 - 21:12:50 CEST

This archive was generated by hypermail 2.2.0 : Sat Sep 24 2011 - 21:24:03 CEST