On Wed, Nov 26, 2014 at 07:02:38PM +0100, Daniel Hahler <[email protected]> wrote: > > No, the symbola font is, by design, unsuitable for a character grid if it > > causes these issues. > > How does libvte and others handle this?
I have no clue - the question you have to ask yourself: how could a font be handled that has characters that don't fit into a terminal cell? I don't think there is any "correct" way to handle that, except by not using that font then (which is probably what urxvt does). > Is there something the font does wrong? Have you ever seen some ascii art displayed using a proportional font? It doesn't work - is this the fault of the font, the ascii art, or the program? The answer is none of them are at fault - the font or program is simply unsuitable for the ascii art, or the ascii art is not suitable for the program etc. It's like trying to use a hammer to screw in a screw - it doesn't work, or at least, not well, and neither the hammer nor the screw are at fault. > While looking into this the last time, I've seen that there are cases > where URxvt can handle a font in a special way (for Japanese?!). I am not aware of any special handling for certain fonts in urxvt - maybe you refer to double-wide glyphs. In general, urxvt can handle characters that take up 1 or 2 cell widths (also 0, and up to 8, but these are special cases), and this information is given by the selected locale. To display correctly, it needs glyphs for characters that are 1 cell wide to fit into one cell, and glyphs for 2 cell characters to fit into 2 cells. If a user requests a certain font, then urxvt tries its best to fit it. This is easy with core fonts, but impossible with xft fonts (xft basically has removed all support for terminal fonts that are still available in the x11 core font protocol), which is why some fonts look very wide, simply because some characters are wider than others. Urxvt cannot simply reserve more space for the glyphs, as the programs that output text rely on the fixed coordinate system - if a cell contains a single-width glyph, then the cells directly to the left and right must also be able to hold glyphs. > Why can't this be applied here? Nobody knows how to fit an elefant into a mousetrap - or rather, nobody knows how to fit too wide characters into a space too small. If you are not interested in glyphs other than, say, ascii, you could limit your font to the ascii range and see if that works (but that isn't the case here). In the end, the only way to get a suitable font is to indeed use a suitable font, namely a charcell one. Xft only supports proportional fonts, has some hacks to imitate monospace fonts (most so-called monospace fonts are, in fact, proportional fonts that are monospace in the ascii range only), and has no support for charcell fonts, so urxvt will always have to guess (it never overestimates though). There can also be issues related to locale/font mismatches, as where a font might have a double-wide glyph for a character that the locale says is single-width. > The link should have been: > http://superuser.com/questions/828690/rendering-of-unicode-symbols-in-urxvt-height-width-vs-gnome-terminal This seems to be an unrelated problem - my guess would be that gnome-terminal (or urxvt) doesn't use the font you specify, it could also be that the glyph doesn't fit and urxvt replaces it (you can check via iso 14755 mode, by holding ctrl-shift and clicking on the characters). I also find it suspicious that gnome-terminal's glyph ends somewhere in the middle of a cell in your picture, indicating that the glyph is too wide to fit (which is why it destroys the M character following in the other pictures). Urxvt has limited support for overlapping characters (I think it allows 50% overlap at most, but I would haver to check first). -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
