<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="-1"><font face="DejaVu Sans">Hi Raimund</font></font><br>
    <br>
    <div class="moz-cite-prefix">Am 29.04.2015 um 14:38 schrieb Raimund
      Steger:<br>
    </div>
    <blockquote
      cite="mid:0ce04bf9e0b068ace29bd66a1c90e3f1.squirrel@steg0.eu"
      type="cite">
      <pre wrap="">
On Wed, April 29, 2015 13:27, Urs Liska wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">[...]
In that case I'd try another approach that *seemed* promising but also
had some issues: returning the family name and comparing that to the
originally given family name.
</pre>
      </blockquote>
      <pre wrap="">
If I may ask, what issues were they? Because even if fontconfig supported
a comparison mode where family name had to be strictly equal (and nothing
else was checked), that's what it would more or less amount to.

Otherwise, see prior discussion ... also about lilypond:

<a class="moz-txt-link-freetext" href="http://thread.gmane.org/gmane.comp.fonts.fontconfig/4251">http://thread.gmane.org/gmane.comp.fonts.fontconfig/4251</a></pre>
    </blockquote>
    <br>
    Oops! It was Werner who directed me to the fontconfig list,
    obviously not recalling having started this thread ;-)<br>
    <br>
    One of the two issues referenced in that thread (the missing
    ligatures on Windows) have (coincidentally) just been fixed several
    weeks ago, but the other thread with the patch at
    <a class="moz-txt-link-freetext" href="http://code.google.com/p/lilypond/issues/detail?id=2761">http://code.google.com/p/lilypond/issues/detail?id=2761</a> seems to be
    quite related. But that patch tries to intercept later, at the Pango
    stage. What I would like to have is something earlier, in the
    fontconfig stage.<br>
    <br>
    Now to the issue:<br>
    I made a modified copy of the function quoted in my initial post:<br>
    <br>
    LY_DEFINE (ly_font_config_font_exists, "ly:font-config-font-exists",
    1, 0, 0,<br>
               (SCM name),<br>
               "Determine if font @var{name} exists.")<br>
    {<br>
      LY_ASSERT_TYPE (scm_is_string, name, 1);<br>
    <br>
      string in_name = ly_scm2string (name).c_str ();<br>
    <br>
      FcPattern *pat = FcPatternCreate ();<br>
      FcValue val;<br>
    <br>
      val.type = FcTypeString;<br>
      val.u.s = (const FcChar8 *)ly_scm2string (name).c_str (); //
    FC_SLANT_ITALIC;<br>
      FcPatternAdd (pat, FC_FAMILY, val, FcFalse);<br>
    <br>
      FcResult result;<br>
      SCM scm_result = SCM_BOOL_F;<br>
    <br>
      FcConfigSubstitute (NULL, pat, FcMatchFont);<br>
      FcDefaultSubstitute (pat);<br>
    <br>
      pat = FcFontMatch (NULL, pat, &result);<br>
      FcChar8 *str = 0;<br>
      if ((FcPatternGetString (pat, FC_FAMILY, 0, &str) ==
    FcResultMatch) &&<br>
          (in_name.compare((char const *)str) == 0))<br>
          scm_result = SCM_BOOL_T;<br>
    <br>
      FcPatternDestroy (pat);<br>
      return scm_result;<br>
    }<br>
    <br>
    This is very similar except that (mainly) the second argument to
    FcPatternGetString is FC_FAMILY instead of FC_FILE. That way I can
    compare the incoming string (which is assumed the family name of the
    font) with the resulting family name.<br>
    <br>
    So this function returns true if the family name in the matched font
    file is the same as the family name used for starting the match.<br>
    This works most of the time (apart from the fact that it's now case
    sensitive, but we'd look into that separately). But there are
    reports of *some* fonts where the returned family is different from
    the actual one. <br>
<a class="moz-txt-link-freetext" href="http://lists.gnu.org/archive/html/lilypond-user/2015-04/msg01300.html">http://lists.gnu.org/archive/html/lilypond-user/2015-04/msg01300.html</a><br>
    reports that the file name returned for fonts Umpush and Kedage are
    wrong. I verified this in my own installation: The family name
    returned by the above function for Umpush is "Tlwg Typo", although
    FontViewer and FontForge both confirm that the family name is
    "Umpush".<br>
    However, fc-match Umpush gives the right result: 'Umpush.ttf:
    "Umpush" "Book"'<br>
    <br>
    So I don't know if that is an issue with fontconfig, some
    peculiarity of the font(s) or an issue with the match configuration
    in the above function.<br>
    <br>
    If I could get a reliable information about this question (together
    with a solution to do a case-insensitive comparison of the input
    with the result) I could settle with this new function.<br>
    Or otherwise I'd like to know about a way to have fontconfig return
    some "failure condition" instead of a replacement if a font isn't
    matched.<br>
    <br>
    Urs<br>
    <br>
    <blockquote
      cite="mid:0ce04bf9e0b068ace29bd66a1c90e3f1.squirrel@steg0.eu"
      type="cite">
      <pre wrap="">

-Raimund


</pre>
    </blockquote>
    <br>
  </body>
</html>