<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Preserve binding when preparing patterns" href="https://bugs.freedesktop.org/show_bug.cgi?id=90330#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Preserve binding when preparing patterns" href="https://bugs.freedesktop.org/show_bug.cgi?id=90330">bug 90330</a> from <a class="email" href="mailto:bungeman@chromium.org" title="bungeman@chromium.org">bungeman@chromium.org</a> <pre>(In reply to Behdad Esfahbod from <a href="show_bug.cgi?id=90330#c16">comment #16</a>) > (In reply to bungeman from <a href="show_bug.cgi?id=90330#c14">comment #14</a>) > > (In reply to Behdad Esfahbod from <a href="show_bug.cgi?id=90330#c9">comment #9</a>) > > > I can think of four different levels of matchness: > > > > > > 1. match: user requested Arial and I found it, > > > > > > 2. approximate: user requested Arial and I found Liberation Sans, > > > > > > 3. fallback: user requested Arial and I found this sans-serif Persian font, > > > > > > 4. no match: user requested Arial, here's some font that covers some > > > characters no other font supports, and it doesn't have anything to do with > > > Arial. > > > > > > The last one is easy to add, it's just all the matching fonts that have > > > score 0 for both family-strong and family-weak match. First one is also > > > easy, that's what my patch does. > > > > > > Right now 2 is also marked as match, that's because 30-metric-aliases.conf > > > does binding="same". If we remove that, then 2 and 3 will become the same. > > > I like to try to distinguish them. > > > > > > So, yes, I think adding more levels to the bindings is possible. We can > > > then decide how to bucket them. We can still bucket them into strong and > > > weak and have the exact same matching algorithm that we have right now, or > > > if we really wanted to, we can add more buckets. > > > > I can think of one more, just to muddy the waters, which is 'preferred'. > > This is when Arial is requested, but the configuration says prefer > > Liberation Sans. In some sense this is a 'match', even though the returned > > font may in some sense be unrelated to the requested font. Maybe this is a > > magic value of setting both the 'match' and 'approximate' bits of the match. > > That was what I called "approximate". How is your 'preferred' level > different? I think what I meant by 'preferred' is like <prefer>, while 'approximate' seems more like <accept>, with <default> matching up with 'fallback'. In other words, with 'preferred' I know that, at least so far as the user is concerned, I got an actual 'perfect' match, even if the font data and resolved pattern disagree. It's not just <accept>able or 'approximate'; it's 'falling forward' as opposed to 'falling back'.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>