<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><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 <span class="vcard"><a class="email" href="mailto:bungeman@chromium.org" title="bungeman@chromium.org">bungeman@chromium.org</a>
</span></b>
<pre>(In reply to Behdad Esfahbod from <a href="show_bug.cgi?id=90330#c16">comment #16</a>)
<span class="quote">> (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?</span >
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>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>