14

This question led to a new package:
hardwrap

In writing error messages and warnings for a package/class, I find it a pain to manually insert \MessageBreaks so that words don't get cruelly bisected because of TeX's max_print_line value (which typically is set to 79). In some cases it's not possible to predict where the \MessageBreak should go because a macro in the warning/error message may be expanded to any length of string.

I'd like to have a macro that would take my warning/error message, expand it (so that any macros are expanded to plain strings), and insert \MessageBreaks in the appropriate places based on the value of max_print_line and LaTeX's per-line prefixes (Package <XXX> Warning: and similar).

(If the value of max_print_line can't be accessed from within TeX, I'd settle for just implementing a greedy word-wrap algorithm with the default line length values.)

Follow-up: Will Robertson and I created the hardwrap package to achieve the desired affect.

Community
  • 1
godbyk
  • 7,737
  • 2
  • 32
  • 47
  • Not a solution so I'll just add it as a comment. If you haven't yet, you might consider diving into the silence package to see how it parses and conditionally removes selected error and warning lines from the output stream. (Apropos of nothing, it's one of my "must have" add-ins during draft document construction.) – Geoffrey Jones Oct 01 '10 at 14:02

3 Answers3

6

I never published the solution I wrote some time ago, but perhaps I should. Here's the link to an example: http://gist.github.com/605753 It's written in the plain old LaTeX programming style; it was a while ago so there are probably a few things in there that I now know how to do in a better way.

There are three examples where the broken text is typeset at different line lengths, and then a fourth example in which it is printed to the terminal. This isn't expandable (if it's possible, it would be difficult to say the least), but for many purposes that won't be an issue.

The code is undocumented, but you should be able to see the gist of it by ignoring everthing before \begin{document}. If you find it useful, I suggest we write a package for CTAN with some documentation and a better interface.

Will Robertson
  • 73,872
  • This looks like a good start (and the code aligns fairly well with what I had in mind). I'll shoot you an email to discuss my use cases in more detail. It'd be great if we could polish it up and post it to CTAN. I think others would find it useful as well. Thanks! – godbyk Oct 01 '10 at 06:08
  • 3
    I see that you have now packaged this as the hardwrap package. Well done, and thanks! – Lev Bishop Nov 11 '10 at 22:07
5

This is an orthogonal comment to my actual answer above; if you have TeX Live 2010, this will work in pdfTeX by default to access the max_print_line variable: (MiKTeX users will need to compile it with -enable-pipes)

\documentclass{article}
\begin{document}
\newcount\maxprintline
\ifnum\pdfshellescape>0
  \maxprintline=\pdfprimitive\input"|kpsewhich -var-value=max_print_line"
\else
  \maxprintline=79 % default
\fi
The variable \verb|max_print_line| is \the\maxprintline.
\end{document}

It won't work if you have -shell-escape turned off entirely (hence the \else clause), but from my point of view there's no reason that restricted shell escape shouldn't always be activated (as it is by default).

This example could be re-written in a more general way to support XeTeX/LuaTeX use as well using the pdftexcmds package.

doncherry
  • 54,637
Will Robertson
  • 73,872
  • I had no idea kpsewhich was capable of doing this. Thanks for the tip! – godbyk Oct 01 '10 at 06:09
  • I didn't either until I just tried it :) – Will Robertson Oct 01 '10 at 06:31
  • Will, would you know of any reasonably useful doco on \pdfprimitive\input (hopefully to the level of explaining why the \input control sequence needs the | pipe before the child process command plus whatever else is going on)? I've hunted high and low down the usual web search laneways with absolutely no success. Even Google code search can't point to a single example line. I'm now doing a full TL2010 install in the vague hope that there'll be some pointers somewhere in there. Also, fyi, MikTeX (2.8 Windows, don't know about 2.9beta) kpsewhich balks on -var-value=. Aargh. :( – Geoffrey Jones Oct 01 '10 at 13:52
  • Hmm, let's see. I first heard about this feature via MiKTeX 2.5. I don't know how long it's been available in TeX Live; I only heard about it again recently. Someone (sorry not me) should contribute some documentation to the TeX Live manual for it. – Will Robertson Oct 01 '10 at 14:24
  • P.S. I don't run Windows any more so I can't help with the kpsewhich thing; I would hope (but am willing to be disappointed) that there's an equivalent way to do the same thing. – Will Robertson Oct 01 '10 at 14:25
  • Will, thanks on both counts. The \pdfprimitive reading proved interesting but sadly, for multiple reasons too long to properly describe here, your code above won't run in a MikTeX environment (even when, too ambitiously, I replaced MikTeX's kpsewhich.exe with the one from TL2010). As for some other MikTeX executable outputting (vs consuming on its cmd line) a functional equivalent of -var-value=max_print_line, prepare to be disappointed, I'm sad to say. The take away is that your code remains fairly platform specific. Thanks again for your good help. – Geoffrey Jones Oct 01 '10 at 14:57
  • Oh well, too bad. I guess for now we can still use the ifplatform package to wrap the whole thing in \ifwindows...\else\maxprintline=79 \fi. – Will Robertson Oct 01 '10 at 16:26
  • I should have been more careful with the way I phrased things. By platform, I meant MiKTeX v TeX Live (rather than Windows v other). I'll post a question on the miktex-users mailing list about how to programatically detect max_print_line and report back here if anything useful turns up. In any event, TL kpsewhich reads max_print_line from texmf.cnf (or something like that). As this is a static value, your technique should be tested for correctness in cases where the user specifies the value at compile time, either by command line switches or in the 1st line of the .tex file. – Geoffrey Jones Oct 02 '10 at 00:31
2

You can't get at max_print_line from within TeX, so that's out for a start. There are also issues with trying to write an automatic line-breaking algorithm. Will Robertson proposed some code a while ago for expl3, but there are issues with TeX's expansion system. So I'm afraid that I think you are stuck having to do things by hand!

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
  • I suspected that accessing max_print_line might not be possible. Do you recall what problems Will encountered? (Feel free to point me to a mailing list thread, if one's available.) Thanks for your response! – godbyk Sep 30 '10 at 21:54