I'd like to to generate some metadata in the log file that I can copy to another application. But the log file is wrapped to 80 columns and I end up with newlines embedded in what I'm putting there. Is there a way around this?

The two ways I know to write to the log file are \message and \immediate\write17. But both of these have the same effect. Is \write17 a special filehandle that only writes wrapped text?

My workaround so far is to write to the auxiliary file between \iffalse...\fi, but I know that's not what the aux file is for. I don't feel like writing this metadata to another file. Yes, I'm being stubborn, but TeX means you can usually get anything you want if you work hard enough. Can I do this?

Edit: Here's something else that doesn't work. Open another filehandle with the same filename.


Then \immediate\write\logfilenowrap{long text} will not wrap lines. But it lops off everything that was in the logfile before this point (of course it does. Opening a file handle usually puts the pointer at the front).

Edit 2: Thanks for all the replies. Consensus is that this is "probably" not possible. I'll go the route of writing metadata to a separate text file.

  • I’m not sure, but maybe something in Will’s answer to the orthogonally named question “How can I word-wrap LaTeX warning/error output?” helps.
    – Caramdir
    Oct 13, 2010 at 3:00
  • I wish, but that seems to be about inserting extra newlines. I want to avoid the ones which are there. Oct 13, 2010 at 3:14
  • As others have said, I don't think this is possible. I'd probably do the explicit hard wrapping ( package to appear shortly) and insert a special char to indicate where to soft-wrap in post-processing. Oct 13, 2010 at 23:43

4 Answers 4


I am pretty sure the wrapping behaviour is hardwired in TeX itself. Why can't you simply write to a separate file instead?

  • 1
    Sure, I can. I just wanted to cut down on the amount of files lying around. If I decide to create a separate file for metadata, I start thinking about RDF which is a favorite pet project/rat hole of mine. So I wanted to keep things simple. Oct 13, 2010 at 12:06

Output file line wrapping is controlled by the max_print_line setting in texmf.cnf (for TeX Live, miktex may have another system that I do not know).

The default setting is:

max_print_line = 79
  • 5
    Miktex knows max_print_line too. It can be set temporarly with the option --max-print-line=150 or in the .ini files by calling e.g. initexmf --edit-config-file pdflatex and then adding max_print_line=150. The second must be done for each compiler which should use this setting. Oct 13, 2010 at 7:42
  • No texmf.cnf file on my machine has this setting in it. But I assume from your answer that whatever it is has to be a positive number. In other words, it can't be shut off. Oct 13, 2010 at 12:08
  • 3
    Correct. But you can give it is very high value :) Oct 13, 2010 at 15:30
  • Excellent answer - it's saved me hours of pain with a similar problem as the OP's. Just for the record on my MacPorts installation of texlive, I did kpsewhich texmf.cnf to locate the configuration file, upped max_print_line to 1000 and then ran texconfig init to put the new setting into effect.
    – Rob Arthan
    Apr 16, 2015 at 13:46
  • 4
    In most shells you can even just add it to your TeX invocation on a one-off basis: max_print_line=10000 tex hello.tex (or whatever). Jun 26, 2017 at 2:46

Try this:

$ max_print_line=14000 pdflatex hello.tex

The 14000 is just a big number.

(This is in @shreevatsaR's comment, but it's easier to read if it is surfaced as an answer.)


For the case of pdflatex provided by MiKTeX, you can set max_print_line directly to some larger number - 191 here:

[IO.File]::WriteAllLines("$Env:AppData\MiKTeX\miktex\config\pdftex.ini", "max_print_line=191")

which creates pdftex.ini with a file encoding that allows it to be read by MiKTeX's pdflatex, ie UTF-8 with no BOM.

You must log in to answer this question.

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