Hi, Sorry for the late reply.
On Sat, Sep 24, 2011 at 4:57 PM, <u-st-j...@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 :)