# How much negative space needed? To recognizably remove a space by letting something be added? For macros whose argument is another macro?

Suppose that one has brea + (notice the space at the end).

brea + is not printed yet. A macro \m{brea +} will replace + with \added ... how then does one define added, imagine it prints a d but only so that

bread results strictly instead of brea d?

\newlength{\test}\settowidth{\test}{~} and then \hspace*{-\test} works inside the .pdf as far as removing the space is concerned. Copying and pasting does not interpret as any space; but if the result brea \added is passed into something like the answer to Extract more than nine arguments that occur periodically in a sentence to use in macros in order to typset, where each space is used as a separator for logic, will it still be recognized?

So if the pdf sees no space character, generally safe to assume LaTeX sees no space, and thus no separator where ~ is parsed as a separator for words? I am correct then in assuming LaTeX sees only bread as the output, because with the negative spacing "added", the threshold for the conditional for a space to be recognized is not flipped? (How it exactly does LaTeX "think" about space inside macros when the argument is the expansion of other macros.)

QUESTION: In other words, how much negative space needed to make sure LaTeX or xparse does not detect any space as being present?

Example: Using code Extract more than nine arguments that occur periodically in a sentence to use in macros in order to typset ... and let \NewDocumentCommand{\form}{m}{\lowercase{#1}} ...

For \fun{ABBB BCCC CDDD DEEE} we expect ABBB BCCC cddd DEEE and get it.

For \fun{ABBB BCCC \hspace{-\test}CDDD DEEE} we expect ABBB BCCCCDDD deee and get ABBB BCCCcddd DEEE ...

• @moewe pdf does have a notion of space characters, it is tex who has not (but one can insert one e.g. with \pdfinterwordspaceon or with tagpdf + interwordspaceon. ) – Ulrike Fischer Mar 23 at 14:36
• @GuidoJorg sorry I don't understand a word. It would be much easier to get what you want, if you would should concrete code. – Ulrike Fischer Mar 23 at 14:43
• TeX sees spaces when they are in the input: I suspect you are talking about PDF viewers and how they 'include' spaces in copy-pasted output. That is beyond TeX's control and depends on which viewer we are talking about. – Joseph Wright Mar 23 at 14:45
• @GuidoJorg there is no length specified in tex that answers your question. Different PDF viewers will have different heuristics for guessing when to ignore a small space as being an inter-letter kern rather than a word space, it is not under TeX's control. – David Carlisle Mar 23 at 14:58
• This and the previous question feel like we are in an 'XY' situation. You are asking to do some things that seem very vague or arbitrary. Probably a question on what you actually want to do would be good, with real data and a real sense of what you need out. – Joseph Wright Mar 23 at 15:14

Your question is very unclear, you could do several things, for example:

1. given {brea } and d remove the space token and so produce bread.

2. Typeset brea remove the skip glue generated by the space token, and then typeset d.

3. Typeset brea skip by the negative of a word space, then typeset d.

\documentclass{article}

\def\z{brea }
\def\zz{d}

\def\AAA#1 {#1}

\begin{document}

1. \expandafter\AAA\z\zz

2. \z  \unskip \zz

3.  \z \hskip -\fontdimen2\font plus -\fontdimen3\font minus -\fontdimen4\font \zz

\end{document}


Note that only (1) here is equivalent to typing bread, with the other variants any font-specified ligatures or kerns between e and d would be lost.

In the generated PDF neither (1) nor (2) will have a space specified (unless (1) has an inter-letter kern and (2) does not) but (3) may or may not have a space specified depending on the ability of the PDF generator to optimize away the two spaces totalling zero width.

Showing Ligatures and kerns:

\documentclass{article}

\def\AAA#1 {#1}

\begin{document}

\def\z{brea }
\def\zz{d}

1. \expandafter\AAA\z\zz

2. \z  \unskip \zz

3.  \z \hskip -\fontdimen2\font plus -\fontdimen3\font minus -\fontdimen4\font \zz

\def\z{V }
\def\zz{o}

1. \expandafter\AAA\z\zz

2. \z  \unskip \zz

3.  \z \hskip -\fontdimen2\font plus -\fontdimen3\font minus -\fontdimen4\font \zz

\def\z{snif }
\def\zz{f}

1. \expandafter\AAA\z\zz

2. \z  \unskip \zz

3.  \z \hskip -\fontdimen2\font plus -\fontdimen3\font minus -\fontdimen4\font \zz

\end{document}

• That clarifies things, will be accepting this answer. It may be that impossible to delete the space in that order of composition, one macro inside the other, where the first can only replace + in brea + with d or some other code like \unskip d and that is what goes into another macro that requires bread and not brea d. So for example \fun{ABBB BCCC\unskip CDDD DEEE} works but \fun{ABBB BCCC \unskip CDDD DEEE} does not and \fun{Abbb Bccc {\hskip -\fontdimen2\font plus -\fontdimen3\font minus -\fontdimen4\font} Cddd Deee} in place of \unskip won't work. – Guido Jorg Mar 23 at 15:14
• @GuidoJorg you have still not said what you mean by "space" here, of the things I suggested, only \AAA removes a space token. \unskip does not act on tokens at all, and removes a glue node (so only does anything after text has been typeset) and the third one of course doesn't remove anything at all it just adds an additional glue node. – David Carlisle Mar 23 at 15:25
• I mean by "space" something that does not trigger as ~ when xparse looks for it. We start with salad toast eggs brea + oats milk and a macro \m transforms + into ? and trying to understand what, if anything "?", makes this into salad toast eggs bread oats milk instead of salad toast eggs brea d oats milk which however in pdf appears "as if" salad toast eggs bread oats milk. Trying to eliminate fragility. Cannot touch the space between "a" in "brea" and "+", only replace + with something. And if I understand correctly, not possible at all, even if nothing is typeset yet. – Guido Jorg Mar 23 at 15:31
• @GuidoJorg you are making it very hard to understand, In normal document code ~ does not parse as a space it is an active character adding linebreak penalties as well as a space. If you are looking at parsing space tokens then only the first version i give above is relevant at all, neither \unskip nor \hskip work at the level of tokens. – David Carlisle Mar 23 at 15:46