Hi,
Sorry for the late reply.
On Sat, Sep 24, 2011 at 4:57 PM, <u-st-jfpt_AT_aetey.se> wrote:
> Having compiled and tested st, I would like to contribute a report.
That's great, thank you.
> Utf-8 and line graphics symbols' handling looks broken on bold text (?).
>
> E.g. mutt shows kanji in From correctly unless the entry is highlighted.
>
> Selecting text which contains kanji may lead to the line being redrawn
> with characters on different horisontal positions. Moving the selection
> pointer right and left makes characters to move either left or right.
>
> This depends also on which font has been picked by st at start, which in turn
> depends on the font collection being available at the X11 server.
>
> The more important issue, choice of the fonts:
>
> With some fonts (depending on the actual server) the display is totally
> broken, cursor being misplaced to the right and characters appearing
> "in two places/halves" or like that. In general it looks like wrong
> font width calculation.
>
> With many other fonts the displayed characters are far from being pretty
> and/or convenient for long use.
>
> My experience (not only with st) says that core fonts are harmful
> and unreliable. If you prefer a different expression, they suck. :)
> I wonder if there is any intention to use a different rendering tool?
Most of the bugs have to do with X core fonts. st default font is the
same as xterm/urxvt. Since it's also the one I use, it's the font with
the best support.
That being said, I _hate_ with passion Xlib, Xft and Xcore font
system. It's either broken and obsolete or convolted to use, painful
to write and modern documentation is nonexistant.
Sometime, I manage to gather enough motivation to work on it, so I
start by looking at rxvt-unicode code.
Throughout the development of st I've looked at a lot of code and
urxvt -- the rewrite of rxvt with unicode in mind -- is the most
helpful. It uses a somewhat sane and readable subset of C++, works
well with a lot of font rendering system and generally tries hard to
please the user eg. looking for unicode chars in different fonts if
it's not present on the current one. All of this by working around
some of the most repulsive API ever made. I don't know how many
developers are working on it but it's a lot of dedication. And _every
time_ I get overwhelmed by this and just give up on st. I'm no font
expert and I'm not especially interested by it. The only previous
experience I had in this was SDL_ttf on one of my pet project, which
is ridiculously simple and straightforward to use albeit not very fast
I guess.
st will never work as well as the next emulator as long as I limit
myself to X11 core libs. It's just too much work and more importantly
it will end up littered with boiler plate code and workaround of X11
apis. I won't do it. st has already too much of it. So if anyone has
preference towards another font system, let's talk about it.
> A nice approach, not implying any dependency on Xft/fontconfig
> can be seen being used by http://www.etalabs.net/uuterm.html
> Wonder if this can be useful for st. The ytty font looks good.
I'd like to know what everyone on the list thinks about this. I've
come across uuterm several times. It's a good piece of software but
having yet another font file format is too much imho. The work on
unicode/input is impressive nonetheless.
> Thanks for working on suckless projects.
Thank you for using them and for giving some feedback :)
Received on Sat Oct 08 2011 - 15:06:25 CEST