[Fontconfig] complicated ordering

[Behdad Esfahbod]

My first take is, if we're ever going to change this considerably, we should
go back and rethink the problem, possibly replace both the language and the
API....  Ie. fontconfig2.

b

On 06/12/2012 10:56 PM, Akira TAGOH wrote:
> Hi,
> 
> fontconfig will read the xml files according to the alphanumerical
> ordering. one may expects that the earlier one would have a priority
> than later one. actually this is true for "prepend", "assign_replace"
> and "append_last" too in some cases. but not for "prepend_first",
> "assign" and "append" due to its behavior. though "prepend_first" may
> be an exception here, because it's a bit special case to use. also I
> believe we are relying on this to apply the user configuration
> effectively.
> 
> Anyway this may be one of reasons why it causes confusion and mess up
> the config directory. so why does this happen? see:
> 
> <match>
>   <test name="family"><string>blahblahblah</string></test>
>   <edit name="family" mode="append">
>     <string>A</string>
>     <string>B</string>
>     <string>C</string>
>   </edit>
> </match>
> 
> This is a typical rule as known as what <accept> does. this ensure the
> order of A/B/C fonts as substitute of blahblahblah there though,
> similar rules reading later will overrides it. see:
> 
> Substitute match
>         pattern any family Equal(ignore blanks) "blahblahblah"
> edit
>         Edit family Append "A" Comma "B" Comma "C";
> 
> Append list before  "blahblahblah"(s) [insert here]
> Append list after  "blahblahblah"(s) "A"(s) "B"(s) "C"(s)
> ...
> Substitute match
>         pattern any family Equal(ignore blanks) "blahblahblah"
> edit
>         Edit family Append "D";
> 
> Append list before  "blahblahblah"(s) [insert here] "A"(s) "B"(s) "C"(s)
> Append list after  "blahblahblah"(s) "D"(s) "A"(s) "B"(s) "C"(s)
> 
> Which isn't expected behavior according to the above prioritization.
> FWIW "append_last" doesn't work in some cases, particularly when other
> rules takes effect to the list prior to the above last one.
> 
> Well, I'm wondering if we may need to change the data structure to
> group according to the edit mode or so for long term solution. for
> short term solution, the above case can be improved with the sort of
> "hook" as the following. e.g. 30-metrics-alias.conf to:
> 
> 30-0-metrics-alias.conf:
> <match>
>   <test name="family"><string>Arial</string></test>
>   <edit name="family" mode="append" binding="same">
>     <string>metrics-alias-Arial</string>
>   </edit>
> </match>
> 
> 30-1-metrics-alias-arial.conf:
> <match>
>   <test name="family"><string>metrics-alias-Arial</string></test>
>   <edit name="family" mode="prepend" binding="same">
>     <string>Liberation Sans</string>
>   </edit>
> </match>
> 
> 30-2-metrics-alias-arial.conf:
> <match>
>   <test name="family"><string>metrics-alias-Arial</string></test>
>   <edit name="family" mode="prepend" binding="same">
>     <string>Albany</string>
>   </edit>
> </match>
> 
> 30-999-metrics-alias-arial.conf:
> <!-- better cleanup perhaps? though it prevents to put similar rules
> later and this enforces to have "30-n" numeric prefix then -->
> <match>
>   <test name="family"><string>metrics-alias-Arial</string></test>
>   <edit name="family" mode="delete" />
> </match>
> 
> After this, no need to put rules prior to 30-metrics-alias.conf any
> more. and it would looks clearer what kind of rules is in the config
> directory. though there are still no way to do "assign"ing with the
> same prioritization.
> 
> How does it look like?
> Any feedback, comments or counterparts are welcome.
> 
> Regards,