Re: xdvipdfmx:fatal: Unable to find TFM file "latt1095".

[Werner LEMBERG]

>> Similarly, I have to regenerate various `.map` files by calling
>> `updmap-user` to integrate my private fonts into TeX.
> 
> Maybe my use-cases are restricted in that I don't switch away from
> some of the most-commonly used fonts, but having many local user
> fonts is on the other extreme of the scale, I would say.

Well, it suffices that you want to add a single font that needs
special handling, for example, an old Type 1 font.  For this you need
a font-specific map file that must be registered (this is, added to
the master map file) by either `updmap-sys` or `updmap-user`.

>> I strongly disagree.  It's definitely not LilyPond's job to decide
>> where the TeX system stores its internal files.
> 
> That's not what I'm proposing here, but I do think LilyPond's build
> system should not mess with global user state.

You call TeXLive's generation of metric files in its own cache
directory tree 'messing with the global user state'?  This sounds
exaggerating...

>> In other words, the build infracture has to adjust this, to be
>> handled outside of LilyPond.
> 
> What is the down-side of LilyPond generating its needed fonts
> locally?

No down-side except additional complexity.

> After all, the build system is even messing around with system-wide
> fonts like TeX Gyre and URW++ which I would argue is far worse.

LilyPond's configuration files for FontConfig are quite a different
case: They manipulate the order how fonts are found at run-time, and
the user might define them in a completely different way for other
programs.

Contrary to that, the Cyrillic TFM files are simply created in the
cache dir and won't change the behaviour of TeXLive in any way.

It's really just a matter of setting `$VARTEXFONTS` (not `$TEXMFVAR`,
sorry), and I really think that this should be done outside of
LilyPond.


    Werner