Since Chinese is rendered correctly at one font size, it looks like uxterm has the ability to draw Chinese chars correctly, but there's something screwy going on that has to do with font size. Chinese is rendered correctly only at Large size, is partly correct at some small sizes, and is entirely unrendered at Huge and Medium sizes. So Arabic text is only rendered at a Huge size, and is drawn totally incorrectly (but with recognizable glyphs). However, they are all the isolated form - and they're drawn left-to-right! Then all the Chinese chars show as little rectangles, but the Arabic appears as Arabic characters. The fun part is when I set the size to Huge. But when I set the size to Large, all the Chinese characters appear correctly, though the Arabic is still little rectangles. When I use CTL+right button to get the Unicode Fonts menu, and change the size to anything less than Large, I see the same behavior, with some Chinese and all Arabic chars shown as rectangles. I have a test file that contains both languages and English. The suggested link to Why doesn't xterm support double-sized characters when using Xft fonts? is for a different problem.I just discovered an even more bizarre behavior in (u)xterm with Chinese and Arabic text. It simply overwrites adjacent characters with the erroneous pixels: Here is a screenshot showing that gnome-terminal does not clip the characters, nor does it interpret those as double-width. Xterm does have a way to adapt to narrow/wide choices for ambiguous width characters, but changing the width of neutral characters is not a feature of xterm. From xterm's standpoint, the problem is likely in the fontconfig metrics. If the terminal uses the font-width, users are confused (because terminal programs are written for a fixed-pitch grid of rows/columns).Ĭorrecting that problem (and making fonts useful to everyone) is what fontconfig is supposed to do. On my mates apple mac, the font appears in Safari but not in chrome.
On my dads laptop, the font doesnt appear what-so-ever in any browser. If the terminal (like xterm) clips the character, users are displeased. On my browser the font appears OK in chrome/IE yet it doesnt appear in mozilla. However, some fonts are (unsurprisingly) developed by East Asians, and have made most of the neutral characters in those fonts double-width. That N means neutral: if the characters were used in an East-Asian context, an implementation could treat them as "full-width" (a misleading term for double-width). EastAsianWidth.txt (see TR11-38) has this information:ġD4A9.1D4AC N # Lu MATHEMATICAL SCRIPT CAPITAL N.MATHEMATICAL SCRIPT CAPITAL QġD49E.1D49F N # Lu MATHEMATICAL SCRIPT CAPITAL C.MATHEMATICAL SCRIPT CAPITAL D UnicodeData.txt gives this information:ġD4AB MATHEMATICAL SCRIPT CAPITAL P Lu 0 L 0050 N ġD49F MATHEMATICAL SCRIPT CAPITAL D Lu 0 L 0044 N īut refers you to the EastAsianWidth.txt file for the actual width.
#Uxterm does not display fonts install#
Uses U+1D4AB and U+1D49F, which xterm and the system agree should occupy one cell on the screen. If you are also interested in cyrillic fonts, install the following fonts.
In some cases, the system's wcwidth is not up-to-date to handle some special characters, and xterm will unnecessarily truncate the cell. Some fonts are worse than others fontconfig doesn't help in this area. For urxvt - it's probably simply ignoring the glyph, since it doesn't follow the font-metrics.
fontconfig silently uses its default font for this. By the way, "fixed" is probably not an entry in fc-list output. to have 12x13 font so that XTerm with the default setting can display as many. xterm generally uses the system's wcwidth function to get a (more) correct estimate of individual character width, and when drawing characters clips, and the erroneous pixels are lost. Split the font up into a 8x16/16x16 pair, and there will be no problems. With xterm, the problem is that the first/last characters go outside the bounding-box which xterm reads from the fontconfig metrics.
0 kommentar(er)
