On Wed, May 16, 2012 at 9:11 AM, Raimund Steger <rs@xxxxxxxx> wrote: > You mean comment #8 in that bug > ( https://bugs.freedesktop.org/show_bug.cgi?id=33644#c8 )? Well I think that > suggestion would be a different interpretation than what is currently > implemented. Yes. and actually it's not a suggestion but the real behavior on current implementation. it may works only on the limited conditions though. that's why I'm a bit concerned about the inconsistency. otherwise all of the combinations for qual's and mode's should be documented to avoid confusion. that would helps us to remember how it is supposed to work ;) > Using other qual's than "any" with FcOpComma in <test> should trigger some > pretty awkward behavior at the moment, because the order of FcOpComma > operands will decide which one is used to check for the position(s) in the > pattern, which is totally counter-intuitive (for example, I think for > qual="all" the last operand would need to get the match, while for > "first"/"not_first" it's likely different). > > But it's not allowed currently anyway ;-) Hmm, I'm not sure. it may be easier to address this if we leave the decision of where the position <edit>s would be applied on to the users? > You mean using <or> etc. not only to calculate ordinal FcTypeBool values, > but also for disjunction of subexpressions in <test>? Yes, something like that. it may be needed particularly if using qual for that purpose is a bad idea. > But still, as you said, the problem where to apply edits if more than one > value matched remains... That's true. it may be relevant each other but should be a separate issue. I'll think about it more though, I tend to think of getting rid of FcOpComma so far. if there are any use-cases that there are no workaround or any other reasonable suggestion, please let me know. -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
