* bug#52979: Modular texlive has problems finding fonts
@ 2022-01-03 16:18 Jelle Licht
2022-01-03 17:06 ` Jelle Licht
0 siblings, 1 reply; 6+ messages in thread
From: Jelle Licht @ 2022-01-03 16:18 UTC (permalink / raw)
To: 52979; +Cc: Ricardo Wurmus
As discussed on #guix on IRC, several folks including myself ran into
issues getting the following some-file.tex:
--8<---------------cut here---------------start------------->8---
\documentclass[11pt]{article}
\begin{document}
Hello friends
\end{document}
--8<---------------cut here---------------end--------------->8---
... to typeset with the following manifest.scm:
--8<---------------cut here---------------start------------->8---
(specifications->manifest
'("texlive-base"
"texlive-fonts-ec"
"texlive-amsfonts"
"texlive-fira"
"texlive-inconsolata"))
--8<---------------cut here---------------end--------------->8---
... with command:
`guix shell --pure coreutils grep sed gawk -m manifest.scm -- pdflatex some-file
Note that the monolithic texlive seems to work:
`guix shell --pure coreutils grep sed gawk texlive -- pdflatex some-file'
On IRC, rekado /w strace identified that texlive does not seem to be
entering the subdirectory containing the font files, as it seems to be
loading texlive-bin's texmf.cnf, instead of the one generated by
`(@ (guix profiles) texlive-configuration)'.
It seems some of the talks in the guix-maintenance repository can
currently also not be built for the same or similar reason.
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#52979: Modular texlive has problems finding fonts
2022-01-03 16:18 bug#52979: Modular texlive has problems finding fonts Jelle Licht
@ 2022-01-03 17:06 ` Jelle Licht
2022-01-04 7:50 ` Ricardo Wurmus
0 siblings, 1 reply; 6+ messages in thread
From: Jelle Licht @ 2022-01-03 17:06 UTC (permalink / raw)
To: 52979; +Cc: Ricardo Wurmus
Jelle Licht <jlicht@fsfe.org> writes:
> As discussed on #guix on IRC, several folks including myself ran into
> issues getting the following some-file.tex:
>
> --8<---------------cut here---------------start------------->8---
> \documentclass[11pt]{article}
> \begin{document}
> Hello friends
> \end{document}
> --8<---------------cut here---------------end--------------->8---
>
> ... to typeset with the following manifest.scm:
> --8<---------------cut here---------------start------------->8---
> (specifications->manifest
> '("texlive-base"
> "texlive-fonts-ec"
> "texlive-amsfonts"
> "texlive-fira"
> "texlive-inconsolata"))
> --8<---------------cut here---------------end--------------->8---
>
> ... with command:
> `guix shell --pure coreutils grep sed gawk -m manifest.scm -- pdflatex some-file
>
> Note that the monolithic texlive seems to work:
> `guix shell --pure coreutils grep sed gawk texlive -- pdflatex some-file'
>
> On IRC, rekado /w strace identified that texlive does not seem to be
> entering the subdirectory containing the font files, as it seems to be
> loading texlive-bin's texmf.cnf, instead of the one generated by
> `(@ (guix profiles) texlive-configuration)'.
The first part here is correct, the second part is not;
It seems texlive's kpathsea uses a heuristic to determine if a directory
is a 'leaf node', where it checks whether there are exactly 2 links in
there[1]; since symlinks do not count towards the link count, a directory
filled with only symlinks to other directories is seen as a leaf node,
and traversal subsequently ends there.
This heuristic is a performance optimisation, as simply doing stat calls
of everything in a directory is slow, according the the kpathsea
authors.
We can disable this optimisation by setting ST_NLINK_TRICK at compile
time. Alternatively, we could try to figure out a way in which our
directory-of-symlinks also contains at least one file.
[1]: That is, "." and ".."
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#52979: Modular texlive has problems finding fonts
2022-01-03 17:06 ` Jelle Licht
@ 2022-01-04 7:50 ` Ricardo Wurmus
2022-01-04 9:19 ` Ricardo Wurmus
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2022-01-04 7:50 UTC (permalink / raw)
To: Jelle Licht; +Cc: 52979
Jelle Licht <jlicht@fsfe.org> writes:
> We can disable this optimisation by setting ST_NLINK_TRICK at compile
> time.
That’s what I did, and it does let kpathsea traverse all the fonts.
Unfortunately, in my tests it does not fix pdflatex. It does, however,
fix xelatex.
Debbugging output suggests that pdflatex encounters the font file
cmr10.tfm, but for some unknown reason doesn’t seem to be satisfied with
it.
--
Ricardo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52979: Modular texlive has problems finding fonts
2022-01-04 7:50 ` Ricardo Wurmus
@ 2022-01-04 9:19 ` Ricardo Wurmus
2022-01-04 9:58 ` Ricardo Wurmus
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2022-01-04 9:19 UTC (permalink / raw)
To: Jelle Licht; +Cc: 52979
Ricardo Wurmus <rekado@elephly.net> writes:
> Jelle Licht <jlicht@fsfe.org> writes:
>
>> We can disable this optimisation by setting ST_NLINK_TRICK at compile
>> time.
>
> That’s what I did, and it does let kpathsea traverse all the fonts.
> Unfortunately, in my tests it does not fix pdflatex. It does, however,
> fix xelatex.
>
> Debbugging output suggests that pdflatex encounters the font file
> cmr10.tfm, but for some unknown reason doesn’t seem to be satisfied with
> it.
It finds cmr10.tfm and then later proceeds to search (with
“must_exist=1”) for bitmap fonts such as dpi656/cmr10.pk (cmr10.656pk)
or dpi659/cmr10.pk (cmr10.659pk).
That’s how it fails:
!pdfTeX error: pdflatex (file cmr10): Font cmr10 at 657 not found
657 is the resolution. The other sizes are due to
KPSE_BITMAP_TOLERANCE; it will also search for alternatives whose
resolution is close enough to the intended size.
I wonder why it bothers with bitmap fonts at all. And why it looks for
this really odd resolution. We have
texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk. Why doesn’t it
look for a font with resolution 600? The resolution 657 must have been
computed somewhere.
--
Ricardo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52979: Modular texlive has problems finding fonts
2022-01-04 9:19 ` Ricardo Wurmus
@ 2022-01-04 9:58 ` Ricardo Wurmus
2022-01-04 14:28 ` Ricardo Wurmus
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2022-01-04 9:58 UTC (permalink / raw)
To: Jelle Licht; +Cc: 52979
Ricardo Wurmus <rekado@elephly.net> writes:
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Jelle Licht <jlicht@fsfe.org> writes:
>>
>>> We can disable this optimisation by setting ST_NLINK_TRICK at compile
>>> time.
>>
>> That’s what I did, and it does let kpathsea traverse all the fonts.
>> Unfortunately, in my tests it does not fix pdflatex. It does, however,
>> fix xelatex.
>>
>> Debbugging output suggests that pdflatex encounters the font file
>> cmr10.tfm, but for some unknown reason doesn’t seem to be satisfied with
>> it.
>
> It finds cmr10.tfm and then later proceeds to search (with
> “must_exist=1”) for bitmap fonts such as dpi656/cmr10.pk (cmr10.656pk)
> or dpi659/cmr10.pk (cmr10.659pk).
>
> That’s how it fails:
>
> !pdfTeX error: pdflatex (file cmr10): Font cmr10 at 657 not found
>
> 657 is the resolution. The other sizes are due to
> KPSE_BITMAP_TOLERANCE; it will also search for alternatives whose
> resolution is close enough to the intended size.
>
> I wonder why it bothers with bitmap fonts at all.
Still wondering, but….
> And why it looks for
> this really odd resolution. We have
> texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk. Why doesn’t it
> look for a font with resolution 600? The resolution 657 must have been
> computed somewhere.
…this mystery is solved. This document works:
--8<---------------cut here---------------start------------->8---
\documentclass[12pt]{article}
\usepackage[utf8]{inputenc}
\begin{document}
Hello frienderino's
\end{document}
--8<---------------cut here---------------end--------------->8---
But this one doesn’t:
--8<---------------cut here---------------start------------->8---
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\begin{document}
Hello frienderino's
\end{document}
--8<---------------cut here---------------end--------------->8---
A font size of 10pt is also fine.
When a font size of 11pt is requested, however, it probably computes a
different DPI value and tries to find matching bitmap fonts of that
size.
It should just generate new fonts then, but I guess mktexpk and all
those tools need to patch their invocations of sed and awk.
So, two things to do here:
1) patch mktexpk, mktexnam, mktexnam.opt,
share/texmf-dist/web2c/mktexupd, et al to find “sed” and “awk”.
2) figure out why pdflatex tries to use bitmap fonts at all when other
files exist.
--
Ricardo
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#52979: Modular texlive has problems finding fonts
2022-01-04 9:58 ` Ricardo Wurmus
@ 2022-01-04 14:28 ` Ricardo Wurmus
0 siblings, 0 replies; 6+ messages in thread
From: Ricardo Wurmus @ 2022-01-04 14:28 UTC (permalink / raw)
To: Jelle Licht; +Cc: 52979-done
Ricardo Wurmus <rekado@elephly.net> writes:
> So, two things to do here:
>
> 1) patch mktexpk, mktexnam, mktexnam.opt,
> share/texmf-dist/web2c/mktexupd, et al to find “sed” and “awk”.
Done.
> 2) figure out why pdflatex tries to use bitmap fonts at all when other
> files exist.
Not done, but the problem has gone away after fixing the former problem.
This now works on wip-texlive, which I just pushed.
--
Ricardo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-04 14:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-03 16:18 bug#52979: Modular texlive has problems finding fonts Jelle Licht
2022-01-03 17:06 ` Jelle Licht
2022-01-04 7:50 ` Ricardo Wurmus
2022-01-04 9:19 ` Ricardo Wurmus
2022-01-04 9:58 ` Ricardo Wurmus
2022-01-04 14:28 ` Ricardo Wurmus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).