Using fonts from the LaTeX Font Catalogue

[Reinhard Kotucha]

On 2021-05-07 at 23:41:54 +0100, David Carlisle wrote:

 > On Fri, 7 May 2021 at 22:47, Reinhard Kotucha <reinhard.kotucha at web.de>
 > wrote:
 >
 > > On 2021-05-07 at 21:12:44 +0200, Ulrike Fischer wrote:
 > >
 > >  > On linux a change of the fontconfig configuration would affect all
 > >  > others applications too.
 > >  >
 > >  > But if you find this troublesome: Make a friendly feature request
 > >  > that texlive 2022 should offer an option ...
 > >
 > > Ulrike, this is easier said than done.  The installer doesn't know
 > > where fontconfig files are located and deriving it from fc-conflist
 > > isn't sufficient either.  There is no fontconfig directory in the
 > > user's HOME directory by default and the one in /etc is not writable
 > > by mortal users.  The only reliable solution is to give some hints in
 > > the documentation.
 > >
 > > Regards,
 > >   Reinhard
 > >
 >
 > That is true but.... How feasible would it be to not configure
 > fontspec to look in the telive tree and instead use a kpathsearch
 > aliases file?  That was originally because someone was mad enough
 > to name the longtable package with more than 8 letters but could we
 > re-write
 > texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.lua in
 > that format so kpathsea can find the fonts using their internal
 > font names?

Jonathan's idea was to make the fonts accessible to text editors as
well.  That's why he's using fontconfig at all.  There is no such need
for Latin scripts and/or Type 1 fonts but it's definitely helpful for
all these exotic South East Asian scripts he had to use at SIL.  He
gave some demonstrations at various conferences.  In order to make OTF
accessible to any other program than TeX itself a fontconfig setup is
unavoidable.

I understand that poeple prefer calling fonts by fontname rather than
by filename.  But instead of using kpathsea's alias mechanism I could
also imagine a lookup table written in TeX which can be read by
fontspec.  That would probably be a bit slower than the kpathsea
approach but if something goes wrong it could write something useful
to the log file.

After all, lookup tables of any kind are extremely painful unless they
can be generated and updated automatically without much effort.

Regards,
  Reinhard

--
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de
------------------------------------------------------------------