>> 1.1 People have been making comments to the effect that the config
>> file language is too expressive[1], and therefore difficult or
>> impossible to process automatically.
KP> I don't think anyone has complained about it's expressive power,
KP> only about the complexity of specifying simple things and the fact
KP> that it's broken.
I seem to recall people complaining that they cannot picture a UI for
editing the Xft config file, as it is too expressive. I may have
misunderstood, though.
KP> If you don't happen to have a 'times' font installed, the edit will change
KP> the rendering of the first face even when it matches 'charter'. That's
KP> wrong.
Okay, I think I see. I'll try to understand the data structures and
come back to you.
KP> The fonts catalogue is generated automatically already, either by
KP> xftcache or the library itself when it discovers fonts not
KP> specified by the cache files.
I'd missed that. That's great.
(Comments on the font matching mechanism delayed. I hate this
thinking business.)
KP> What I'd like to keep is the exposed fundemental font properties
KP> and then provide boolean functions XftCoreP, XftFreeTypeP that test
KP> which rasterizer "owns" the underlying data.
Okay. (Yay, Keith is suffering from Lisp exposure!)
>> [1] It's not Turing-complete, though. It looks like all config files
>> terminate.
KP> I avoided adding a looping construct to keep people from writing complete
KP> applications in the config file syntax.
My ability to write config files has been significantly hindered by
the absence of the S and K combinators.
Juliusz
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
