[Fontconfig-bugs] [Bug 90330] Preserve binding when preparing patterns

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90330

--- Comment #20 from Behdad Esfahbod <freedesktop at behdad.org> ---
(In reply to bungeman from comment #19)
> (In reply to Behdad Esfahbod from comment #16)
> > (In reply to bungeman from comment #14)
> > > (In reply to Behdad Esfahbod from comment #9)
> > > > 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'.

<prefer> seems to only be used currently to implement virtual families (sans,
serif, etc).  Also, if user asked for "Arial", it's hard to say anything other
than Arial is a better match...

If user asked for "sans", however, it would be useful to tell them that indeed
what we returned is the preferred sans font...

So yeah, I think I like adding additional meanings to <accept>, <default>, and
<prefer>.

So now we have two competing proposals: binding strength, versus the
accept/default/prefer mechanism.

In fact, now that I check, I think we are not consistent in how we use those
things.  For example, 30-metric-aliases has these:

        <alias binding="same">
          <family>Nimbus Sans</family>
          <default>
          <family>Helvetica</family>
          </default>
        </alias>

I think the default should be accept instead.

So, <prefer> currently happens without binding="same".  I guess it should. 
Generally, sounds like <accept> and <prefer> should go with binding="same",
whereas <default> shouldn't.  Does that sound about right?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20150519/7cb49b08/attachment.html>