Oh, sorry. There is a typo. Three but not two Chinese fonts can be displayed. Two of them are too large, and the third one is not bitmap font.
On Sun, Apr 26, 2009 at 7:57 PM, Haomin Wen <[email protected]> wrote: > Hello, > > I am sorry but I really hope dwm can switch to using pango. > > X fonts are broken and not well supported, at least in Ubuntu. I have six > Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two > of them only support 16 pixel and 24 pixel size. They are too large, given > that my dpi is as low as 75. The other font is arphic ukai, but it is not > bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap > font and covers many encodings, but I can use it for no obvious reason. > > It seems to me that pango's powerfulness comes with almost no cost. > > For programmers, there is little difference, or at least it generally will > not increase SLOC. > > For users, they just need to set the font to something like "Sans-10" or > "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig > is powerful. User can set spacing, priority, antialias, hinting, and a lot > more properties of fonts, which is necessary for certain fonts. > > Of course pango is not as comman as xlib, and it even depends on Cairo, but > it works. > > Sincerely, > > Haomin Wen > > On Sun, Apr 26, 2009 at 6:38 PM, Anselm R Garbe <[email protected]> wrote: > >> 2009/4/26 Szabolcs Nagy <[email protected]>: >> > On 4/25/09, Anselm R Garbe <[email protected]> wrote: >> >> 1. One idea is getting rid of the dwm bar altogether and to print the >> >> dwm state to stdout when it changes, however after thinking carefully >> >> about it I conclude that having the bar build-in is definately a >> >> stayer. It's so much simpler than the hassle with an external bar, not >> >> worth it. So very unlikely. >> > >> > if external bar is a hassle then inter-process communication is broken >> > in our systems >> > >> > if built-in bar is a hassle then x is broken (unable to display text) >> >> Well, an external bar is a hassle because it would increase the >> overall complexity if it's assumed to be implemented properly (or in a >> fashion like what we got). One has to specify handling where the bar >> appears, which size, and all kinds of interface handling between the >> bar and dwm. >> >> >> 2. Another idea is to switch to another dependency for the rendering >> >> bit which could possibly be cairo. After all I'm nearly giving up the >> >> hope that X font handling will ever be fixed and work properly, >> > >> > $ du -h /usr/lib/libcairo.a >> > 608K /usr/lib/libcairo.a >> > >> > pango seems to be slightly smaller, but i don't know what these libs >> > do exactly.. >> >> They do fairly more than what we need for a single bar. So let's stick >> to what we got. >> >> > imo it's not suckless, but it can be a temporary solution until x is >> fixed >> >> Knowing who drives the X development I gave up any hope that X will >> ever be fixed, more the contrary. >> >> I think the only solution is dws, which needs more assistance and >> which can be based on legacy crap. Important is that dws provides >> decent interfaces and possibly a legacy X interface on top of it. I >> think that's the long term plan we should achieve. But it'll take a >> long time with the resources we got atm (I hoped GSoC would sponsor us >> somehow to get started into that direction). >> >> >> 3. A third idea for legacy support is, that I tend to add a >> >> compile-time option or a specific Rule extension that let's you set to >> >> reparent all clients or certain clients which are broken >> > >> > rule extension won't work as these applications tend not to set >> > class,instance,name properly >> >> Yea that's a pity and that makes the rules more questionable, perhaps >> I should make them simpler or changing the mechanism eg having a >> "catch next map" function instead which applies a certain rule to the >> next window which is mapped. >> >> Kind regards, >> --Anselm >> >> >
