<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#c21">Comment # 21</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:bugs.freedesktop@karlt.net" title="Karl Tomlinson <bugs.freedesktop@karlt.net>"> Karl Tomlinson</a> <pre>(In reply to bungeman from <a href="show_bug.cgi?id=90330#c19">comment #19</a>) > 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'. I wonder whether this distinction is really necessary. If the app does want to act differently on knowledge of preferred vs accept, then it can look at the edited match/sort pattern. I suspect this could be difficult to prescribe and implement as a property on a single family. If the app requests "Favourite font", "Helvetica" and the user prefers Arial over Helvetica, then I'm not sure that an Arial match is really preferred rather than accepted. I also suspect this would be overloading binding too much with something is really something quite different. (See next comment.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>