Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

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.

share|improve this question
    
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 1 '10 at 14:02

3 Answers 3

up vote 6 down vote accepted

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.

share|improve this answer
    
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 1 '10 at 6: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

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!

share|improve this answer
    
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

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.

share|improve this answer
    
I had no idea kpsewhich was capable of doing this. Thanks for the tip! –  godbyk Oct 1 '10 at 6:09
    
I didn't either until I just tried it :) –  Will Robertson Oct 1 '10 at 6: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 1 '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 1 '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 1 '10 at 14:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.