<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - freetype port: font fallback mechanism can try harder"
   href="https://bugs.webkit.org/show_bug.cgi?id=77437#c12">Comment # 12</a>
              on <a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - freetype port: font fallback mechanism can try harder"
   href="https://bugs.webkit.org/show_bug.cgi?id=77437">bug 77437</a>
              from <span class="vcard"><a class="email" href="mailto:mcatanzaro&#64;igalia.com" title="Michael Catanzaro &lt;mcatanzaro&#64;igalia.com&gt;"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
        <pre>Epiphany sets the WebKit default to GNOME's default... by default.

Anyway, this bug only covers the case where no generic fallback (sans-serif) is in the font-family list. The case of font-family: Arial,Helvetica,sans-serif; is <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Freetype] Always allow font matching for strong aliases"
   href="show_bug.cgi?id=147057">bug #147057</a>, where I am pretty sure we have agreed on a solution (though the discussion occurred before I filed that bug).

In the case where sans-serif is not in the list (this bug)... after processing the entire font-family list and finding no match, there are two possibilities for what we should do: (a) allow fontconfig to match on the first font, which might return a font that's better than the browser's default -- that's what the patch in this bug implements -- or (b) use the default font always.

I've been going back and forth on whether (a) is a good idea. Yesterday I thought &quot;if there is no generic fallback listed, we might as well perform unrestricted fontconfig matching to try to find the best font.&quot; Today I think it's better to fix <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Freetype] Always allow font matching for strong aliases"
   href="show_bug.cgi?id=147057">bug #147057</a> and leave it at that: never perform fontconfig matching except for fonts that are extremely similar to each other (strongly-aliased fonts), and use our default font otherwise. That would be sufficient to fix both of these particular issues, since Arial would get matched to Liberation Sans. So I am inclined to say WONTFIX for this bug, but I will leave that choice to Martin Robinson (although maybe Martin Jackson has an opinion on this too?).

Actually, there is one more thing we should change here: the lastResortFallbackFont should be sans. It seems we use serif currently, but that's silly, it should be sans. <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Clean up FontCache::lastResortFallbackFont"
   href="show_bug.cgi?id=147088">Bug #147088</a>.

BTW the patch status was that the general idea was approved, but not the implementation (r- means &quot;review denied&quot;). Also, I think there needs to be layout tests for this, since they would be easy to write. We have a jhbuild environment for running tests to make sure that our font settings are always the same.</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>