# Two supposedly equivalent ways to typeset a space result in different renderings

Consider the following TeX manuscript:

\font\myfont=cmtt14\myfont
x x

x\char32x
\end


When it is compiled with pdftex, it typesets thus:

Why is there a difference between the two rows in the way the space is rendered?

• I have a feeling this might be an 'X-Y' question: is the aim purely interest or is there some application you have in mind? – Joseph Wright Sep 26 '17 at 19:09
• @JosephWright: What's an 'X-Y' question? At any rate, it is partly out of pure interest, and partly because I'm experimenting with the way LaTeX3 deals with spaces inside token lists, and I'd like to be able to view the spaces readily. – Evan Aad Sep 26 '17 at 19:14
• An X-Y question is where someone asks one thing (X) but really wants to do another (Y). Here, to see tokens, typesetting them is not the right approach: one can decompose a token list easily in expl3 using \tl_show_analysis:N. I'll post a (non)-answer about the underlying problem shortly. – Joseph Wright Sep 26 '17 at 19:21
• @JosephWright: OK, thanks. By the way, I don't understand how \pdfinterwordspaceon is meant to be used. I tried the example on p. 29 of The pdfTeX User Manual (April 20, 2017), but I see no difference between the spaces before the \pdfinterwordspaceon is used and afterwords. In particular, the spaces are not rendered as ␣'s. – Evan Aad Sep 26 '17 at 19:24
• \char<number> doesn't produce a token; it is an unexpandable construction that's sent directly to the typesetter, meaning “print character in slot <number> in the current font. – egreg Sep 26 '17 at 19:49

TeX does not use characters for spaces in output: rather these are 'gaps' between the glyphs. When you consider that characters are of fixed size whilst TeX is all about varying spacing to get 'good' paragraphs, that makes sense. As such, the glyph held at position 32 of a font has nothing to do with typesetting normal spaces: it doesn't even have to be space-related.

Recent efforts related to accessible and reflowable PDFs have led to the inclusion of 'faked' space inclusion primitives in pdfTeX: see \pdfinterwordspaceon. However, this relies on a specific font (which just contains a fake space), and is really not intended for general alteration of output. (To date this functionality is also not widely used and so may well nto work perfectly.)

• Thanks. What about the (non)-answer you were going to post about the underlying problem? (Something involving \tl_show_analysis:N.) – Evan Aad Sep 26 '17 at 19:56

The construction \char<number> is conceptually different from typing the character with that number.

For instance, \char\^^M will not produce an end-of-line character (with category code 5, under the normal TeX conventions). Similarly, \char32 will not produce a space token.

The instruction \char<number> is passed directly to the typesetting stage, and means

print the glyph in slot <number> of the current font

For instance, OT1 encoded fonts normally have the small slash for the Polish “suppressed ell”, that is ł and Ł. If you look in plain.tex, you'll find

663 \def\l{\char32l}
664 \def\L{\leavevmode\setbox0\hbox{L}\hbox to\wd0{\hss\char32L}}


(line numbers added for reference). However, fixed width font in the OT1 encoding have the “visible space” glyph in slot 32. Try processing with plain TeX

\l \quad \tt \l \bye


and you'll see.

It should be noted that characters inserted via \char will participate to hyphenation as if they were input directly (and fit some of the hyphenation patterns) and form ligatures, because ligatures are tied to the slots in the current font, rather than to character tokens.

\charf lagsta\charf \charf

\leavevmode
\vbox{\hsize=0pt \hfuzz=\maxdimen % no warning
\hskip 0pt supercalifragilisticexpialidocious
}\hskip 4em
\vbox{\hsize=0pt \hfuzz=\maxdimen % no warning
\hskip 0pt superc\chara lifr\chara gilisticexpi\chara lidocious
}

\l \tt \l

\bye
`