6

I'm trying to make a typeset form using some custom commands that I've built. Part of that effort is making "blanks": macros for blank space where someone can write something in after the document has been printed. Their definition is in the formfields package (information about how to get that is at the bottom of the post).

I ran into the following issue: I had some of the blanks inside of tables, and the blanks in the left column weren't coming up flush to the end of first column. Eventually, I traced that to the following change, demonstrated in these two tables from this MWE:

\documentclass[draft]{article}
\usepackage{tabu}
\usepackage{formfields}
\usepackage[left=1.0in, right=.5in, top=.7in, bottom=.7in]{geometry}

\begin{document}
% not flush, and blanks don't all come up to same place.
\begin{tabu} {X<{ \hspace{.5em} }>{ \hspace{.5em} }X}
    \field{thing}& \hrulefill\\
    \blank & \hrulefill\\
    \field{thing}& \hrulefill\\
\end{tabu}

% all blanks flush with each other at right end of 1st column.
\begin{tabu} {X<{\hspace{.5em}}>{\hspace{.5em}}X}
    \field{thing}& \hrulefill\\
    \blank & \hrulefill\\
    \field{thing}& \hrulefill\\
\end{tabu}

% same as second table.
\begin{tabu} {XX}
    \field{thing}& \hrulefill\\
    \blank & \hrulefill\\
    \field{thing}& \hrulefill\\
\end{tabu}
\end{document}

Why do the blanks and fields all come up flush against the end of the first column in the second and third tables, but not the first? I could understand if I were doing something different to each row, but in both of these tables, I don't think I'm doing anything different that would make the rules not align with each other on the right side; I assume this means the spaces at the end of the first column in the different rows of the 1st table are of different lengths. I don't see why that should be the case. I ask this question because I couldn't figure out that the spaces in my table header were the culprit for several weeks. I'm hoping to get some insight as to how to diagnose and debug this sort of thing. If you can, please pay special attention to that.

Part of the problem seems to be the spaces within the < and > column specifiers in my table, because the second table from the MWE has the spaces removed, and all the blanks come up flush with the end of the first column. I'm not suprised the spaces stop the blanks from becoming flush with the right end of the 1st column, but I don't understand why the different blanks would act differently.

Additional Resources

A picture of the trouble (the red rectangles were added later, they show where the lines aren't flush with each other).

Zoomed in picture of the first (top) table:

formfields.sty can be obtained here

  • 1
    In your picture the lines look flush left everywhere? This aside, you might be interested in the command \ProvidesExplPackage for formfield.sty. – Andrew Dec 6 '18 at 5:27
  • @Andrew I'll get around to that later on. For now, I'm trying to get stuff to work before worrying too much about things like that. As for the lines looking flush everywhere... I don't see that. There's not a big difference between the different lines in the frst table, but there's a difference. The middle blank sticks out further than the blank on the top and bottom in table 1. – Beelzebielsk Dec 6 '18 at 5:52
  • @Andrew Lemme know if there's anything I can do to make it stick out a little more. Maybe I can draw a vertical line near the ends of the blanks so you can compare how much the lines go beyond the blank? – Beelzebielsk Dec 6 '18 at 5:54
  • @Andrew I misread your comment. The lines are all flush left, yes, but not flush right everywhere. While I see how to fix this, I don't understand the fix. I can see why adding spaces would make the right ends of the blanks not flush with the right edge of their column, but I can't understand why they wouldn't be flush on the right with each other. If I take the spaces away from the < and > column things, then the trouble goes away, despite the different commands (\field uses \blank anyway, so they're not that different). But... why should it go away? Why was there trouble at all? – Beelzebielsk Dec 6 '18 at 19:13
  • @Andrew Hm. Unfortunate. Well, it's not a problem for this one example, though perhaps I'll make similar mistakes in the future. In the meantime, I think I'll go mess around with it, see what sorts of whitespace I can put in there that will and won't cause the behavior. Maybe I'll get some understanding out of that. – Beelzebielsk Dec 7 '18 at 16:33
2
+50

One way to debug this is to look at the produced output box. You can see a representation of it when you add

\tracingoutput=1
\showboxbreadth=100
\showboxdepth=20

at the begin of your document. You can then compare the differences between the three tables and its cells so that you at least see to what result TeX has come.

Why is there extra space only in some places?

This is the part further investigation is necessary. In table 3 it's pretty obvious, there's no space defined in the column formats, so no space is added to the output. In table 2 only \hspaces, internally \hskips, i.e. glue elements, are added to the output boxes. In table 1 some of the space characters also find their way into the output, perhaps due to the way TeX parses macro parameters.

Whenever a glue appears at the begin and end of a box/line, it is removed from the output. This is why the \hspace is removed from table 2/column 1. However, in table 2/column 2 it's still there at the left because the \null box (which is there in column 1 too) appears before it. I have no idea why the \hspace is still gone in column 1.

Why are there difference spaces in the first table?

Let's compare the relevant parts of the boxes of lines 1 and 2 of table 1/column 1:

% line 1                                        line 2
  \hbox(0.0+0.0)x0.0                            \hbox(0.0+0.0)x0.0
  \OT1/cmr/m/n/10 t
  \OT1/cmr/m/n/10 h
  \OT1/cmr/m/n/10 i
  \OT1/cmr/m/n/10 n
  \OT1/cmr/m/n/10 g
  \OT1/cmr/m/n/10 :
  \leaders 3.50006
    \rule(*+*)x0.4

  \leaders 0.0 plus 1.0fill                     \leaders 0.0 plus 1.0fill
    \rule(0.4+0.0)x*                              \rule(0.4+0.0)x*
  \kern 0.0                                     \kern 0.0
  \glue 4.44444 plus 3.33331 minus 0.55556      \glue 3.33333 plus 1.66666 minus 1.11111
%       ^------------ here's the difference ----------^
  \glue 5.0                                     \glue 5.0

  \penalty 10000                                \penalty 10000
  \rule(0.0+0.0)x0.0                            \rule(0.0+0.0)x0.0
  \penalty 10000                                \penalty 10000
  \glue(\parfillskip) 0.0 plus 1.0fil           \glue(\parfillskip) 0.0 plus 1.0fil
  \glue(\rightskip) 0.0                         \glue(\rightskip) 0.0

You can see the two \glue values here in the middle part. The first is from one of the space characters, the second from the \hspace. Both should get their natural width, as there's the leader with a 1.0fill that occupies all the remaining space. Now why is the first one larger than the second?

The answer is the way TeX handles spaces after punctuation marks. By \sfcode, each character in TeX can be assigned a space factor to which can stretch the space after it. Because your \field macro prints a : at the end, the active space factor when the space character is processed is still the one assigned to :, which is 2000 in the default setting. This makes the following space slightly larger than the one at natural width in line 2 by adding a so called "extra space".

Try adding \sfcode`\:=1000 at the begin of your document to force the natural width and the spaces at the end become the same width:

enter image description here

  • Hm. Yeah, it would seem you're right. I tried \frenchspacing, which I believe evens out the spacing across different punctuation marks, and the difference went away. – Beelzebielsk Dec 9 '18 at 17:11
  • How did you trace the spacing to the space factor? I think if I'd paid attention to the space factor section in the TeXBook, and looked at the trace, I wouldn't have come to this conclusion. I wouldn't have come to any conclusion. – Beelzebielsk Dec 9 '18 at 18:12
  • @Beelzebielsk That part actually puzzled me quite some time. Because of the context it appeared in, I knew there was no stretching of the space involved. So I read in The TeXbook how the natural width of spaces is calculated, and when I found the mention of space factors if had finally clicked. – siracusa Dec 10 '18 at 1:40
2

It's not at all clear why you're adding \hspace in the column specifications.

Anyway,

\begin{tabu} {X<{ \hspace{.5em} }>{ \hspace{.5em} }X}

does much more than adding .5em, because it adds “space”, “half a quad”, “space”. However, in the first column the final space is removed when the paragraph is finished up. This also happens in your second example, where the trailing \hspace{.5em} is eaten up.

You could use {\hspace*{.5em}}, but there's a much simpler solution.

\documentclass[draft]{article}
\usepackage{tabu}
\usepackage{formfields}
\usepackage[left=1.0in, right=.5in, top=.7in, bottom=.7in]{geometry}

\begin{document}
% not flush, and blanks don't all come up to same place.
\begin{tabu} {X<{\hspace*{.5em}}>{\hspace*{.5em}}X}
    \field{thing}& \hrulefill\\
    \blank & \hrulefill\\
    \field{thing}& \hrulefill\\
\end{tabu}

\bigskip

% all blanks flush with each other at right end of 1st column.
\begin{tabu} {X @{\hspace{\dimexpr1em+2\tabcolsep}} X}
    \field{thing}& \hrulefill\\
    \blank & \hrulefill\\
    \field{thing}& \hrulefill\\
\end{tabu}

\end{document}

enter image description here

The black boxes are apparently due to a wrong definition for \field.

  • The black boxes are there when the draft option is turned on. The spaces in the column header, I did it to try and "spread the space evenely between the columns". A few months later, I have no idea what that means or why it was necessary. The question isn't about why it's there, it's about why something I thought was innocuous was the source of a visual bug, and ultimately about how to catch this. – Beelzebielsk Dec 9 '18 at 16:27
  • I may have been unclear. There's no problem in my document, currently. My trouble is that I don't understand how the addition of those literal spaces (not hspace, but " ") causes the rules to not be flush with each other on their right. The amount of space left at the end of each row of the 1st table isn't uniform. In the 2nd and 3rd tables, the amount of space is uniform. How do the changes to the column specifications change how uniform the spaces are? I expect them to be uniform in the 1st table because the directions for adding space are the same for all the rows. – Beelzebielsk Dec 9 '18 at 16:39
  • It's fine for there to be space added. It's fine for the rules in the 1st column of the 1st table to not be flush with the column's end, but why would they not be aligned on the right with each other? If every row of the 1st table was like the 1st and 3rd rows, I wouldn't have seen a problem. The rules would all line up on the right side. – Beelzebielsk Dec 9 '18 at 16:41
  • @Beelzebielsk If you don't control precisely the horizontal spacings in table, you can get surprises. As the other answer points out, the difference is in the space factor due to the colon, in a really surprising fashion. I'm inclined to think that tabu has a part in this, but I'm not going to investigate further. – egreg Dec 9 '18 at 16:50
  • Yeah, that's the source of my recent rash of questions. I can't be precise without knowing precisely what's going on. There's always some part of TeX working in the background which causes surprising behavior in something that looks innocuous. I'm glad I'm learning more, but getting what I want from latex means understanding tex. I can see why someone would say something like this now. The start of my work is writing what I want. The rest of my work is now writing what I don't want TeX to do, for all the many ways it can interfere. – Beelzebielsk Dec 9 '18 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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