1

I had a file and a file-name of 71 characters, no space-character, several digits and some special 'danish' characters as well. The 'latexmk' processed the file but did not run the 'biber' sufficient times or did not run 'biber' at all; no \cite-entry was processed orderly.

xelatex, biber and xelatex were able to process the original file including every \cite-entry and the like.

When I reduced the name of the file considerably I was able to process the file in latexmk.

Is there a limit of length for a file to be processed by latexmk?

Improve this question
8
  • I'm more worried about the Danish letters, were there still æøå in the reduced length? Have you tried the same file lenght, but only with ascii chars in the name? I'd generally recommend not using non-ascii in filenames
    – daleif
    Dec 11, 2019 at 15:43
  • It is not that it does not run biber sufficient times, it never runs it period.
    – daleif
    Dec 11, 2019 at 15:59
  • 1
    From my tests, works fine with file names up to 66 with non-ascii in the file name. latexmk + xelatex failes on 67 chars. Running it with latexmk -pdf no problem at all. So it seems to a parsing issue somewhere. There is no issues at all with latexmk + xelatex when there is no non-ascii in the file name, even for much longer file names
    – daleif
    Dec 11, 2019 at 16:12
  • 3
    The problem is indeed a parsing issue. On an initial run of pdflatex or xelatex, latexmk detects the use of biber or bibtex by a No file ...bbl line in the log file. With long enough file names, the line is wrapped, and latexmk has to deal with that. Pdflatex strictly wraps at a line length of 79 bytes, which latexmk handles. But in the presence of non-ascii characters, xelatex appears to miscount bytes and wraps lines differently, so latexmk doesn't correctly detect wrapped lines. It's more-or-less a bug in xelatex, but I can try to have latexmk work around it.
    – John Collins
    Dec 11, 2019 at 20:40
  • 3
    Work around: If you can't avoid such long filenames, run biber once manually, after which latexmk will work because it won't depend on parsing the log file.
    – John Collins
    Dec 11, 2019 at 20:42

1 Answer 1

Reset to default
1

As John Collins points out in the comments, the problem here was that latexmk has to parse the .log file to find out whether or not the .bbl file was found by LaTeX. LaTeX usually wraps long lines in the output, but XeLaTeX would not always wrap the line at the expected place (pdfLaTeX wraps at 79 bytes, but XeLaTeX doesn't comply to this limit when non-ASCII chars are present), so latexmk would fail to parse the line correctly.

John Collins also suggests a workaround: Call Biber manually for the first time. Then the .bbl will be present and latexmk won't have to rely on .log file parsing to know whether or not to invoke Biber again.

The recent latexmk update to version 4.67 (https://tug.org/pipermail/tex-live-commits/2020-January/012017.html) addresses this issue. It should now be possible to use longer file names.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .