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

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