Modular texlive has problems finding fonts

  • Done
  • quality assurance status badge
Details
2 participants
  • Jelle Licht
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Jelle Licht
Severity
normal

Debbugs page

Jelle Licht wrote 3 years ago
(address . bug-guix@gnu.org)
86k0fg3i9y.fsf@fsfe.org
As discussed on #guix on IRC, several folks including myself ran into
issues getting the following some-file.tex:

Toggle snippet (6 lines)
\documentclass[11pt]{article}
\begin{document}
Hello friends
\end{document}

... to typeset with the following manifest.scm:
Toggle snippet (8 lines)
(specifications->manifest
'("texlive-base"
"texlive-fonts-ec"
"texlive-amsfonts"
"texlive-fira"
"texlive-inconsolata"))

... 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.
Jelle Licht wrote 3 years ago
(address . 52979@debbugs.gnu.org)(name . Ricardo Wurmus)(address . rekado@elephly.net)
86ee5o3g1t.fsf@fsfe.org
Jelle Licht <jlicht@fsfe.org> writes:

Toggle quote (30 lines)
> 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 ".."
Ricardo Wurmus wrote 3 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 52979@debbugs.gnu.org)
87zgocdjkl.fsf@elephly.net
Jelle Licht <jlicht@fsfe.org> writes:

Toggle quote (3 lines)
> 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
Ricardo Wurmus wrote 3 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 52979@debbugs.gnu.org)
87v8yzestw.fsf@elephly.net
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (13 lines)
> 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
Ricardo Wurmus wrote 3 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 52979@debbugs.gnu.org)
87r19neqdh.fsf@elephly.net
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (29 lines)
> 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….

Toggle quote (6 lines)
> 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:

Toggle snippet (7 lines)
\documentclass[12pt]{article}
\usepackage[utf8]{inputenc}
\begin{document}
Hello frienderino's
\end{document}

But this one doesn’t:

Toggle snippet (7 lines)
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\begin{document}
Hello frienderino's
\end{document}

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
Ricardo Wurmus wrote 3 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 52979-done@debbugs.gnu.org)
87mtkbefrm.fsf@elephly.net
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (5 lines)
> 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.

Toggle quote (3 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 52979@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52979
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help