# Text created with a \newcommand overflows into margin (not xspace question)

I am aware of the use of xspace to handle the space after a macro in different situations. However, it seems that I cannot avoid having my text created with a \newcommand from running into the margin.

It seems the length of the expanded text is ignored when it is word wrapped. Is there a simple fix?

Here is the minimal example latex code.

\documentclass[11pt]{article}

\usepackage{xspace}

\newcommand{\DirectTransformation{\ensuremath{\mathtt{DirectTransformation}}\xspace}

\begin{document}
In the following carefully crafted sentence, the macro will overflow
\DirectTransformation into the margin.  Subsequent sentences show
where the margin of the document actually ends and that the first
sentence always overflows.  Is there a solution to this problem?

\end{document}


which gives

-
why math and \mathtt rather than just \texttt? \newcommand isn't relevant here you would get the same if you used \texttt{DirectTransformation} directly in place. (if you used texttt you could have teh option of re-enabling hypehation which is turned off by default –  David Carlisle Jul 21 '12 at 23:59

Two possible options. First, use \texttt{} and add one or more discretionary hyphens. E.g.:

\renewcommand{\DirectTransformation}{\texttt{Direct\-Transformation}}


Alternatively, somewhat like the other answer, you could try to change the 'emergency stretch' to a given amount in the preamble:

\emergencystretch=1em


But this is a 'global' solution, which you should only consider using if there are too many paragraphs with your unbreakable but long word. Otherwise, as @JLDiaz suggested, \sloppy is probably a better bet.

(Also, your example is missing a closing brace on the macro name. But apparently I can't edit questions if the changes aren't at least 6 characters worth or more.)

-

Math uses its own rules for line breaking. A line break inside math mode usually happens at relational symbols. In any case, TeX will never break nor hyphenate a variable name, and that is what DirectTransformation is for TeX.

Faced with that "unbreakable" word, TeX must choose between leaving the word sticking out at the end of the line, or breaking the line just before that word. The first case in undesirable, so TeX asigns to it some amount of "uglyness". The second case will require to insert extra spacing between words, in order to fully justify the line. This extra space is considered also ugly, so this decision would increase the uglyness of the paragraph. TeX tries several alternatives to divide the paragraph into lines and chooses the one with the minimum "uglyness".

The default parameters used by TeX to assign the uglyness values of each alternative are designed so that they favour the first case (word protruding the right margin) over the second one (too much space between words, also called an underful box).

This has nothing to do with \newcommand but instead with the fact that the word is unbreakable. You can have the same result if you put that word into a \mbox. For example:

In the following carefully crafted sentence, the macro will overflow
\mbox{DirectTransformation} into the margin.  Subsequent sentences show
where the margin of the document actually ends and that the first
sentence always overflows.  Is there a solution to this problem?


Produces:

TeX's default parameters can be tweaked. One mild tweak is to put the command \sloppy in the preamble. This changes the parameters to make TeX more tolerant with underfull lines. Using this in your example will lead to:

Comparing these two outputs, it is hard to believe that TeX "thinks" that the first one is less ugly than the second one, but this is how TeX sees beauty.

Instead of tweaking TeX's default parameters, usually it is a better idea to try to reword the paragraph so that the conflictive word does not happen at the end of the line. Of course this is a kind of fine-tuning that has sense only in the final stages of the edition.

-
This description of unbreakable words was very helpful in general. –  ngsa Jul 24 '12 at 16:55