BTW please send to the list too... On Mon, Jan 16, 2012 at 7:51 PM, lolilolicon <lolilolicon@xxxxxxxxx> wrote: > On Mon, Jan 16, 2012 at 5:24 PM, Akira TAGOH <akira@xxxxxxxxx> wrote: >> I'm assuming that the document is always true to explain the behavior. >> IMHO that would be good to discuss changing it as long as it less >> affects for existing applications though. > > I see your comments in bug #33644 about <or> now. Indeed, people > naturally want to do bitwise OR <test>s in <match>, and <family>s in > <alias>, as demonstrated by the configs 30-metric-aliases.conf, > 40-nonlatin.conf and 45-latin.conf. Honestly I'm not quote sure how to use that... no examples nor any cases anyone uses it in the real world. explicitly using a bitwise element would be obvious though, it may looks too complicated. > >>> First, the configs shipped with fontconfig have <alias> followed by a >>> bunch of <family> elements, namely 30-metric-aliases.conf, >>> 40-nonlatin.conf and 45-latin.conf. I thought it's wrong configuration, >>> but now I realize it's not that simple. >> >> I suppose it's a bug for the config in fontconfig. please file a bug then. > > OK, I will. > >>> Second, I tested with the equivalent <match> rules: >>> -- SNIP -- >>> and I get exactly the same results as before. >> >> I'm not sure what this "before" points to, given that it doesn't work >> as you expected as in the original mail, this is also correct behavior >> and also documented. see also a comment in >> https://bugs.freedesktop.org/show_bug.cgi?id=33644#c2 > > Very helpful, thanks. A warning should really be printed if it's invalid > syntax, unless we make it valid syntax :) > >>> $ fc-match lolfont >>> HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman" >> >> That may depends on the priority of the "Helbetica LT Std". though >> these seems some bugs in fontconfig to deal with <alias>. it may be >> one of them. > > "Helvetica LT Std" does not have any special priority in my setup, i.e. no > other rule regarding it at all. I'm pretty sure it's a bug. Not in > <alias>, though, because the equivalent <match> with the three <string>s > in <test> gives the same result. If it behaves differently after removing the line of <family> for lolfont, that may be a side-effect of a bug of multiple <family> elements in <test> as <alias> is a syntactic sugar for that, I guess. -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig