On Sun, Mar 26, 2023 at 03:21:35PM +0200, Hans Hagen via ntg-context wrote:
On 3/26/2023 3:08 PM, Carlos via ntg-context wrote:
On Sun, Mar 26, 2023 at 01:04:30PM +0200, Henning Hraban Ramm via ntg-context wrote:
Am 25.03.23 um 23:42 schrieb Carlos via ntg-context:
fonts | names | 3092 afm files checked, okay fonts | names | identifying tree font files with suffix 'AFM' fonts | names | scanning path '/home/ce/.texlive2023/texmf-config' for AFM files
fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' fonts | names | variable 'OSFONTDIR' specifies path '/usr/share/fonts' fonts | names | globbing path '/home/ce/**.otf'
There is something strange here. Is maybe TEXMFHOME set?
Since you use a TeX live installation, some other texmfcnf.lua or texmf.cnf might interfere. Look into /usr/local/texlive/2023/
I'll check again to make sure. But keep in mind this issue predates the official TeX Live installation . I've been using the distro prepackaged for a while. And yes. It's always been there. Sort of like, it came with the system :)
Since it scans everything in your home directory, maybe TEXMFHOME or OSFONTDIR is set to ~ (instead ~/texmf) there?
But even if there was a conflict, it wouldn't justify to be scanninp up everything viciously.
Well, if fonts can be anywhere that means checking for them anywhere. TeX installations have some directory setup for a reason. Imagine that you set up the installation to include that wildcard path in TEXINPUITS then every run that whole tree would get scanned for a file you ask for and that is not in the current directory. The whole idea behind TDS and defining paths for specific kind of files it to limit lookups.
Hans, plesae… please, You know deep inside that the above paragraph does not make any sense even after writing it convincingly. The fact that fonts can be anywhere DOES NOT mean that a program whatever that program may be is following whatever TDS sets in place or is presumably setting in place.. or much less — regardless of fonts' location, that a program out there needs to act erratically. Careless. To say the least. Bear with me in this one (I'm just a bit tired):
Look at the same issue from another system perspective. I said system perspective because simply put there is so much one can do whenever you're dealing with a multiuser program such as TeX Live. Bear wiht me here:
I have Void Linux on a spare system. Let's put aside for a second the inconsistencies surrounding texmfcnf.lua there. We can get back to it later And there's plenty of it taht can also be said.
Do you know what is the method used to handle this problem? By folder.
If I were to invoke mtxrun --script cache --erase it should behave accordingly. Or I'd expect it to act accordingly. The same with mtxrun --script font --reload Of course, it doesn't help if texmfcnf.lua sets anything else by doing otherwise.
Does it sound far-fetched? Maybe. But it certainly makes more sense than looking up everything under every imaginable worktree by which presumably there can be fonts. Which 100 percent of the time there's none.
But What fonts are to be found on cache and headers folders? tfm, afm, otf? come on!
But then again. Even in Void Linux (a system for which concurrent files lookups seem to be working now under the right expectations) threw errors back and forth with both context.lua mtx-context.lua and base.lua unknown scripts, before eventually getting it right. (that may be a misnomer) I ought to say I got it right, I guess.
Were mtxrun --generate or mtxrun --script cache --erase called out? Of course.
Which led me to read about that pesky behavior here for example:
But the above was put aside. And there soon followed a matter-of-fact «it's not broken in TeX Live» statement.
Well. If looked at from that narow angle, yes, I guess.
Recall this is with a prepackaged TeXLive or the one put out by the devs. And I was aware of that. Not the case here. I'm just mentioning it because that's the method used or what it's doing on that spare system as of now. Lookups for every folder.
So far I've had to move about 7-8 folders. About 6 of them are owned by root, the rest are owned by root but symlinked to user.
I would not do that, instead I'd fix ny OSFONTDIR path. Even with some directories moved you still end with plenty useless scanning.
I'm working on it.
And to top it off, after doing so, it didn't stop there, heck no, it also wanted to snoop in a folder with cache and headers.
To be honest. I woudlnt' know what to make of it. If it's simply looking into the permissions of the directories first, or the fact that it has a colon separated pattern. But. Then again. The other folders didn't have it.
I'll let you know.
What if you use the regular context installation (not texlive) and see what that does? Maybe that gives a clue.
I already did that. Before installing TeX Live.
The events' chronology on Alpine goes something like this:
texlive prepackaged > ConTeXt standalone > TeX Live 2023
(btw, the official texlive 2023 was tested on windows, linux and osx so there must be something special at your end.)
:) I guess. The testers missed other systems. Such as mine. Didn't they? So the tests weren't thorough. Can you say they were thorough? I can't.
Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : firstname.lastname@example.org / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___________________________________________________________________________________