On Mon, Sep 06, 2010 at 01:48:15PM +0100, Ethan Grammatikidis wrote:
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.

In that example it's not too bad, but you still have all of those extra elements that I don't think you could remember if you were constructing the string by hand. And the FC string was just an example. Normally you don't need any attributes at all, with the possible exception of style, which covers bold, italic, ... The only reasin I use pixelsize is that without it my bitmap fonts get scaled.

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 going to rewrite it in scheme. YAML would definitely be an improvement, but I'd rather just have a font selection in scheme. It's simpler than having to parse and then execute a spec, and more powerful. At least, it would allow me to replace the XML monstrosity at the end of this message with the somewhat more reasonable scheme version, but I think I can probably do better. I haven't written the matcher yet, so I'll decide on the config format after that. At the least, the scheme engine could ceratainly parse a YAML file.

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.

Yes, Plan 9's font system is much simpler. It was designed to support large character sets from the start. X now supports font sets, too, but they don't work well at all. As for Xft, yes, it does support rendering glyphs that a font doesn't include, but not as well as you might expect, and I'm not entirely certain of the rules. URxvt had to resort to its own glyph selection algorithm.


(defrules 'font
  (#t
   (set! rgba fc:none,
         hinting #t
         hintstyle fc:hintfull
         antialias #t)))
(defrules 'pattern
  ((= family "ProggyCleanTT")
   (set! antialias #f))
  ((= family "Lucida")
   (set! family "Lucida Std"))
  ((= family "Lucida Sans")
   (set! family "Lucida Sans Std"))
  ((= family "Lucida Typewriter")
   (set! family "Lucida Typewriter Std"))
(deffilters 'font
  ((not scalable)
   #t))

<fontconfig>
    <match target="font">
        <edit mode="assign" name="rgba">
            <const>none</const>
        </edit>
        <edit mode="assign" name="hinting">
            <bool>true</bool>
        </edit>
        <edit mode="assign" name="hintstyle">
            <const>hintfull</const>
        </edit>
        <edit mode="assign" name="antialias">
            <bool>true</bool>
        </edit>
    </match>
    <match target="pattern" name="family">
        <test name="family" qual="any">
            <string>ProggyCleanTT</string>
        </test>
        <edit mode="assign" name="antialias">
            <bool>false</bool>
        </edit>
    </match>
    <match target="pattern" name="family">
        <test name="family" qual="any">
            <string>Lucida</string>
        </test>
        <edit mode="assign" name="family">
            <string>Lucida Std</string>
        </edit>
    </match>
    <match target="pattern" name="family">
        <test name="family" qual="any">
            <string>Lucida Sans</string>
        </test>
        <edit mode="assign" name="family">
            <string>Lucida Sans Std</string>
        </edit>
    </match>
    <match target="pattern" name="family">
        <test name="family" qual="any">
            <string>LucidaTypewriter</string>
        </test>
        <edit mode="assign" name="family">
            <string>Lucida Typewriter Std</string>
        </edit>
    </match>
    <selectfont>
        <acceptfont>
            <pattern>
                <patelt name="scalable">
                    <bool>false</bool>
                </patelt>
            </pattern>
        </acceptfont>
    </selectfont>
</fontconfig>

--
Kris Maglione

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
        --Brian W. Kernighan


Reply via email to