<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">Philip Taylor wrote:<br>
    </div>
    <blockquote cite="mid:57C4A083.9090607@Rhul.Ac.Uk" type="cite">
      <pre wrap="">Thank you Jonathan -- indeed it does [reveal from where the fonts are loaded] :

However, I cannot find "Frederika2016.otf" in C:/Windows/fonts (even as System Administrator), and do not know how to interpret "D^^A/Windows/fonts/Frederika2016.otf".
</pre>
    </blockquote>
    One aspect of the mystery is now solved.  Although Windows Explorer
    claims that there is no file called "Frederika*.*" in
    C:/Windows/Fonts, an elevated command prompt and a simple DIR
    reveals that the files (there were two) exist, and at the same
    elevated command prompt they can be (and have been) deleted.  The
    font has been re-installed, the test file now compiles correctly,
    and the two missing GREEK NUMBER signs appear as intended.<br>
    <br>
    However :<br>
    <br>
    1) The compilation [1, attached] takes 20 seconds to compile /every
    time/, almost all of that apparently being concerned with the font
    loading<br>
    2) The log file [2, attached] contains cryptic references to (e.g.,)
    <br>
    <br>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;"> ->
      K^^A/Windows/fonts/Frederika2016.otf</p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;">       
      and<br>
    </p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;"> ->
      b^^N/Windows/fonts/pala.ttf<br>
    </p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;"><br>
      where I do not understand the meaning of K^^A and b^^N.<br>
    </p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;"><br>
      Given that, during my earlier test, I was able to see XeTeX
      re-populate C:\TeX\Live\2016\texmf-var\fonts\cache when I emptied
      it by hand, it is not clear to me why it cannot now re-create the
      cache(s) once and once only and then allow my compilation to
      proceed without a further need to re-create the caches on
      subsequent runs.  Could a clue to the problem lie in the name of
      the only one of the cache files to have been modified today :<br>
      <blockquote type="cite">d031bbba323fd9e5b47e0ee5a0353f11-x86.cache-7.NEW</blockquote>
      The first line of this file contains the string :<br>
    </p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;"><br>
      <blockquote type="cite">Version:1.0
        StartHTML:0000000107
        EndHTML:0000000598
        StartFragment:0000000538
        EndFragment:0000000562
        <meta name="qrichtext" content="1">
        <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
          margin-right:0px; -qt-block-indent:0; text-indent:0px;"><!--StartFragment-->C:/Windows/fonts</p>
      </blockquote>
      The suggestion by Akira-san resolves the problem :<br>
    </p>
    <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
      margin-right:0px; -qt-block-indent:0; text-indent:0px;">
      <blockquote type="cite">In a file
        <br>
        .../texlive2016/texmf.cnf
        <br>
        create a line
        <br>
        <br>
        FC_CACHEDIR = c:/your/writable/directory
      </blockquote>
      Following this change, the second and subsequent compilations
      proceed at the anticipated speed.<br>
    </p>
    <br>
    Philip Taylor<br>
  </body>
</html>