# Problems with column alignment in the lstlisting environment

I'm having some problems with the column alignment in the lstlisting environment provided by listings.sty.

In fixed-width column alignment mode, whatever the typeface being used, listings are supposed to be presented with one character per column, where the columns have uniform widths (which may be set by the author). However, I find this not actually to be the case with certain input.

Minimal example:

\documentclass{article}
\usepackage{listings}
\begin{document}

\begin{lstlisting}[columns=fixed]
columnar alignment maligned multiple narrow characters?
1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234
\end{lstlisting}

\end{document}


Result:

Note that the second line is exactly one character shorter than the first, which is observed at the far right-hand side. However, the alignment in the middle is somewhat ruined at the occurance of every l character (ambiguous alignment of u in columnar with 3 or 4; ambiguous alignment of i, g, and n in alignment with 1, 2, 3, and 4; etc.). This problem is not helped by tweaking the alignment, by e.g. replacing fixed with {[l]fixed} for the column alignment.

Is this a known problem? Is there any fix for it?

-

This is the expected/default output for columns=fixed in an lstlisting environment. From the listings package documentation:

Now, the fixed format puts n characters into a box of width n x base width, where the base width is 0.6em in the example. The format shrinks and stretches the space between the characters to make them fit the box.

That is, the alignment is not meant to consistent across lines within the listing. Rather, the chunks of code is placed in boxes and the spacing is modified with no regard for anything else except the box width. Even the example presented in the documentation (page 19) exhibits this behaviour:

Notice the misaligned i in write (line 1) and print (line 2) due to the wider w.

Even if you modified your minimal example to the following:

\documentclass{article}
\usepackage{listings}
\begin{document}

\begin{lstlisting}[columns=fixed]
colu mnar alig nmen tmal igne dmul tipl enar rowc hara cters?
1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234
\end{lstlisting}

\end{document}


attempting to align the listing column-wise, the output looks better, but still has the same issues you mention:

Notice the misalignment between mnar and 6789 (due to m); tmal and 1234 (again due to m); rowc and 6789 (due to w), etc.

The only way around this is to use a mono-spaced font for your entire listing, using (say) basicstyle=\ttfamily:

-
Hmm. What you're describing sounds an awful lot like the flexible spacing option. "Common to all is that the input characters are translated into a sequence of basic output units"; but surely what counts as a unit differs between the four alignment options, as otherwise the horrible spacing in the example text for the documentation (e.g. the words MEN and WOMEN) would not occur; even in my question, there's an odd space just before the n in columnar which should not occur if it's of one block. Are you quite sure that the blocks are meant to be computed on the syntactic level? –  Niel de Beaudrap Aug 29 '11 at 9:41
Basically, what I am asking is this –– this behaviour is obviously known, because you (at least) are taking it for granted that this is normal, and are able to use the documentation itself as evidence. Does anyone view this behaviour as desirable, that the lstlisting ruins the spacing between characters if you use fixed spacing, but doesn't do it well enough to successfully achieve columnar alignment? Or is this an issue which is somehow famously difficult to solve? Basically, I'm asking: is it worth addressing it as a bug to the package maintainer? –  Niel de Beaudrap Aug 29 '11 at 9:48
I'm accepting this answer because it seems to explain what my problem is; although I'm unhappy with the fact that the problem exists, because it essentially defeats the purpose of the various spacing options in listings.sty. –  Niel de Beaudrap Sep 25 '11 at 1:08
Regardless of the outcome here, it is definitely advisable to follow up with the package maintainer(s). They would have the best idea whether it could be included in future releases, whether a temporary fix exists, or even whether there are others that have expressed similar interests. –  Werner Sep 25 '11 at 5:58