[Fontconfig] Marking glyphs as deliberately blank, per font

[Krzysztof Kotlenga]

Nicolas Mailhot wrote:

> Le jeudi 26 novembre 2009 à 22:06 +0100, Krzysztof Kotlenga a écrit :
>> Nicolas Mailhot wrote:
>>> Le jeudi 26 novembre 2009 à 13:14 -0500, Behdad Esfahbod a écrit :
>>> 
>>> <font>
>>>  <family>some family name</family>
>>>  <style>some style name</style>
>>>  <format>some font format name</format>
>>>  <unicode>
>>>    <min>some-unicode-value</min>
>>>    <max>some-greater-unicode-value</max>
>>>  <unicode>
>>>  <lang>some fontconfig orth id</lang>
>>> </font>
>> 
>> It looks like a reinvention of what is already there.
>> 
>> <match target="font">
>>   <test name="family"><string>...</string></test>
>>   <test name="style"><string>...</string></test>
>>   <test name="whatever">...</test>
>>   <edit name="whatever">...</edit>
>> </match>
> 
> What is already there is so verbose very few people use it
                                      ^^^^^^^^
You never know...

> and when they do use it they usually mix up things and it does not
> work the way they expect it to work due to all the layers of
> verbosity that get in the way of human parsing

I agree it's verbose, but not without a reason. You seem to miss the
fact that fontconfig allows arbitrary properties. This is something
that can't be done with tags.

> I've never seen problems with simple succinct statements like :
>         <alias>
>         [snip]
>         </alias>

Well, to quote fonts-conf(5), "alias elements provide a shorthand
notation (...)". So, you'd like to see introduced another form of
shorthand notation. Another change causing user visible complexity to
grow (!). As a user, I wish it won't happen.

> OTOH the match target/test is a reinvention of emacs' let's use lisp
> syntax as configuration syntax hell

This doesn't sound like technical merit.

>>> And it would also be useful to define a <not/> operator, for example
>>> <not>
>>>  <lang>ja_Ja</lang>
>>> </not>
>> 
>> <test compare="not_eq">
>> ?
> 
> Another oververbose statement

You can't please everyone. :)

PS. Isn't this horribly OT?
PPS. I'm sorry for sending this twice.

-- 
The fact is, most software is crap, and most software developers
are lazy and stupid. Same as most customers are stupid too.
                         -- Hua Zhong, Linux Kernel Mailing List