Re: [dev] [patch] dmenu - support for xft font rendering

On 6 Sep 2010, at 3:53 am, Kris Maglione wrote:

> On Mon, Sep 06, 2010 at 02:20:47AM +0100, Ethan Grammatikidis wrote:
>>
>> On 1 Sep 2010, at 8:30 pm, Kris Maglione wrote:
>>
>>> On Wed, Sep 01, 2010 at 06:00:17PM +0100, Ethan Grammatikidis wrote:
>>>> Connor Lane Smith wrote:
>>>>> If someone were to write a simple clean xft patch for libdraw
>>>>> it could be useful, perhaps even integrated into mainline.
>>>> This may just be my limited perspective, or it may be my upset
>>>> stomach talking, but I'm very surprised to see xft seriously
>>>> suggested in this mailing list. Xft is (to me) synonymous with
>>>> the transition of X.org from something bad but usable into a
>>>> black box nightmare best left to distro tools to cope with.
>>>> Maybe it wasn't so bad for other people, maybe it got better.
>>>
>>> As bad as Xft/fontconfig is, the X font system is worse. At least
>>> with Xft, you can copy just about any font you like (TTF, OTF,
>>> Type-1, PCF, BDF) to ~/.fonts and then use it. You also don't
>>> need to worry about having scaled bitmaps for every font size
>>> that you want. And, probably most importantly, you don't need to
>>> deal with hoary and inscrutable X font spec strings.
>>
>> cd .fonts
>> mkfontdir
>> xset +fp ~/.fonts # or if you ran that already: xset fp rehash
>>
>> Granted, xset not a wonderful program itself, being essentially a
>> multi-call binary with a number of entirely unrelated tasks and
>> no syntax consistency whatsoever.
>>
>> Scaled bitmaps are an issue for the web, certainly. I've never
>> personally needed them elsewhere except in apps I'd really
>> describe as having brain-damaged UIs. I would like to have web
>> pages rendered in such a way as to not need precise font sizes.
>
> You're not considering the fact that a) that won't work if you're
> connecting over a network, b) you can't use scalable fonts without
> a font server, c) quite a few other problems that I can't think of
> off of the top of my head but bite from time to time.

a) Yeah, I guess you're right. There's a lot to be said for fonts
rendered by the application rather than by the display server.

b) I'm sure I used Type 1 scalable fonts. Then again perhaps that was
way back when I had xfs set up. I didn't like the Type 1 fonts, &
looking back that was probably due to the lack of any worthwhile
hinting whatsoever.

>
>> Speaking of UIs, good ones can make excellent tutorials. 10-20
>> minutes with xfontsel and X font spec strings look a whole lot
>> better. They may still be a little hard to hand-edit but not
>> entirely so and xfontsel itself is a pretty good tool for when
>> they are. After using xfontsel for years the Gtk+2 font selector's
>> lack of any means to filter the font list was unbearable!
>> Honestly, that lack of filtering was one of the bigger things
>> turning me off Xft, and I don't know if the situation's improved.
>
> That's no excuse for the absolutely appalling specification format.
> Fontconfig may be a reeking pile of insanity, but at least you can
> read its specs. Usually a font name by itself is enough, or with a
> size, 'Terminus - 12', and beyond that, it's still easy enough to
> parse:
> Terminus:style=Bold:pixelsize=12:charset=iso10646-1
>
> as opposed to
> -*-terminus-bold-*-*-*-12-*-*-*-*-*-iso10646-1

12-pixel terminus bold in a utf-8 encoding. I'd honestly rather read
the X font spec, the Xft style all seems to run together. Then again,
given a decent and decently-rendered font maybe the Xft spec strings
are readable. Seems a bit of a chicken-and-egg problem with my eyes.

>
> Also note that the charset is almost entirely superfluous in the
> first spec, but the second is a crap shoot without it.
> And at least with the former you can run 'fc-list | grep Terminus'
> to get a list of the available opts. Try grepping 'xlsfonts -l'
> some time. On my machine, it freezes my X server for 30 seconds,
> prints a few hundred lines to TTYv1, and finally returnes a few
> hundred lines of similarly inscrutable font specs for each font. I
> still say that fontconfig is crap, but it's certainly less crap
> than the X font system, if only it weren't for the damned XML
> configuration garbage.

Oh aye, xlsfonts -l does return a lot of junk, and holding up the X
server is nasty.

Regarding the XML configuration, would it help to convert it to YAML?
Just mentioning it because I've heard YAML is a lot more human-
readable than XML and XML can be converted to/from YAML.

>
>> I'm not really trying to advocate X font strings as such, nor
>> Xlib; one of my monitors really needs anti-aliasing and UTF-8
>> support is a good thing, referring to your comment below. I'm not
>> sure what I am getting at.
>
> I use Xft with wmii wihout antialiasing, because I do need UTF-8
> support and the X font system doesn't get it right for me. And I'm
> tired of dealing with those blighted font specs.

I've noticed how Plan's font system allows you to make a unicode font
by writing a text file referencing other fonts, and thought that was
light-years ahead of X fonts complete inability to do so. Are you
saying Xft can automatically fall back to other fonts for missing
characters? That would impress me.

>
> --
> Kris Maglione
>
> The pessimist complains about the wind; the optimist expects it to
> change; the realist adjusts the sails.
> --William Arthur Ward
>
>
Received on Mon Sep 06 2010 - 14:48:15 CEST