Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thinspace will stay at a break but not hairspace, is this intended ? #2

Closed
jfbu opened this issue Oct 28, 2016 · 10 comments
Closed

thinspace will stay at a break but not hairspace, is this intended ? #2

jfbu opened this issue Oct 28, 2016 · 10 comments
Assignees

Comments

@jfbu
Copy link

jfbu commented Oct 28, 2016

it is a question really, because I didn't check Unicode specs, but github is lacking an interface for that,

THIN SPACE is defined as \leavevmode\,\linebreak[0], hence if a break occurs at the penalty, the kern \, will stay at end of line.
The break may also happen before the kern, then it will disappear at start of next line.

edit: correction, due to the penalty following the kern, no break can happen before the kern (I got confused: if the kern had been followed by some glue, a break could happen before the kern; but not with penalties). TeX will complain of an overfull horizontal box, the kern will hang their invisibly in the margin.

On the other hand the HAIR SPACE is simply a glue, hence will not stay at end of a line. Is it deliberate that the two differ ? (this example is not convincing see next posts)

\documentclass{article}
\begin{document}

\begin{minipage}{\dimexpr 100pt+.16667em\relax}
\rule{100pt}{1pt}\,\linebreak[0]a

\rule{\linewidth}{1pt}

X\hrulefill X

\rule{\linewidth}{1pt}\rlap{\smash{\rule{0.1pt}{5\baselineskip}}}
\end{minipage}
\end{document}

capture d ecran 2016-10-28 a 09 39 31

@jfbu
Copy link
Author

jfbu commented Oct 28, 2016

Perhaps this is more relevant, produces the same image and shows the phenomenon of the kern staying at end of line.

\begin{minipage}{\dimexpr 100pt+.16667em\relax}
\hrulefill\,\linebreak[0]

a

\rule{\linewidth}{1pt}

X\hrulefill X

\rule{\linewidth}{1pt}\rlap{\smash{\rule{0.1pt}{5\baselineskip}}}

\end{minipage}

@jfbu
Copy link
Author

jfbu commented Oct 28, 2016

ok, perhaps a more convincing example

\documentclass{article}
\begin{document}

\begin{minipage}{\dimexpr 100pt+.16667em\relax}
\rule{45pt}{1pt}\ \ \rule{45.2pt}{1pt}x\,\linebreak[0]y

\rule{\linewidth}{1pt}\rlap{\smash{\rule{0.1pt}{2\baselineskip}}}
\end{minipage}
\end{document}

capture d ecran 2016-10-28 a 10 05 14

and adding \showoutput and examining the log one sees the kern refused to disappear in a break. The space at middle of line was shrinked to allow the kern to stay without creating overfull box.

.....\hbox(4.30554+0.0)x101.66672, glue set - 0.965  <=== compressed glue
......\hbox(0.0+0.0)x0.0
......\hbox(1.0+0.0)x45.0
.......\rule(1.0+0.0)x45.0
......\glue 3.33333 plus 1.66666 minus 1.11111
......\glue 3.33333 plus 1.66666 minus 1.11111
......\hbox(1.0+0.0)x45.2
.......\rule(1.0+0.0)x45.2
......\OT1/cmr/m/n/10 x
......\kern 1.66672 <=== kern is here at end of line
......\penalty 0
......\glue(\rightskip) 0.0

@wilx wilx self-assigned this Oct 28, 2016
wilx added a commit that referenced this issue Oct 28, 2016
- Add test case.
- Use `\leavevmode\linebreak[0]\,` for THIN SPACE.
@wilx
Copy link
Owner

wilx commented Oct 28, 2016

Thank you for the bug report. I have pushed a fix for this that uses \newunicodechar{ }{\leavevmode\linebreak[0]\,} for THIN SPACE instead.

@jfbu
Copy link
Author

jfbu commented Oct 28, 2016

and what about FIGURE SPACE and PUNCTUATION SPACE ? the \hphantom creates boxes which do not allow breaks. Again, I know nothing about how Unicode defines the behaviour of those at end of lines... but perhaps a \linebreak[0] could be added too after the \leavevmode.

@jfbu
Copy link
Author

jfbu commented Oct 28, 2016

about my last comment, perhaps wrong proposal: the box will be there at start of new line. For better uniformity with THIN SPACE the code would have to create a \kern, not a box. Hence, not use \hphantom. But again, perhaps a FIGURE SPACE must always have in all circumstances the width of a figure, then having such a space at start of next line after a break is ok. No idea what's the thing to do.

@wilx
Copy link
Owner

wilx commented Oct 28, 2016

and what about FIGURE SPACE and PUNCTUATION SPACE ? the \hphantom creates boxes which do not allow breaks. Again, I know nothing about how Unicode defines the behaviour of those at end of lines... but perhaps a \linebreak[0] could be added too after the \leavevmode.

According to Whitespace character - Wikipedia, FIGURE SPACE is not breakable space. However, I think you have a point with PUNCTUATION SPACE.

wilx added a commit that referenced this issue Oct 28, 2016
- Fix another aspect of GitHub issue #2.
- Use \hspace{\fontcharwd \font `,} for punctuation space so that it is
  wrappable.
@wilx
Copy link
Owner

wilx commented Oct 28, 2016

I have pushed 22f9ec7 to fix the issue with PUNCTUATION SPACE.

wilx added a commit that referenced this issue Oct 28, 2016
@jfbu
Copy link
Author

jfbu commented Oct 28, 2016

This whole matter is complicated because for some reason LaTeX implemented \, as \kern. But for example the \hspace ultimately does a \hskip. If we put \leavevmode[0] after an \hspace it is like \allowbreak\hspace{...}. But after a \kern there is no permutation hence it remains like \kern <dimen>\allowbreak and not \allowbreak\kern<dimen>.

Notice that Plain TeX has a \, only for math mode. The \, of LaTeX works both in text and math mode. It does a \thinspace in text mode, but this \thinspace is \kern .16667em.

wilx added a commit that referenced this issue Oct 28, 2016
- Use \allowbreak instead of \linebreak[0] for THIN SPACE.
- GitHub issue #2.
@wilx
Copy link
Owner

wilx commented Oct 28, 2016

So I have made the change to use \allowbreak.

wilx added a commit that referenced this issue Oct 28, 2016
- Use \allowbreak instead of \linebreak[0] for THIN SPACE.
- GitHub issue #2 and #3.
@wilx
Copy link
Owner

wilx commented Dec 27, 2016

I think this is fixed now.

@wilx wilx closed this as completed Dec 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants