With graphics layout TeX can't break line containing successive \tikz drawings

[seloumi]

\documentclass{article}
\usepackage{tikz}

\usepackage[bidi=basic,arabic,provide=*,layout=graphics]{babel}

\parindent=0pt

\newcommand{\tikzcircle}{\tikz[baseline=-0.5ex]{\node[draw=red,circle,minimum width=2em,align=center] at (0,0) {1};}\hspace{5pt}}

\begin{document}

\foreach \x in {1,...,30}{%
\tikzcircle
}%

\end{document}

[u-fischer]

Why do you use \hspace* instead of simply \hspace?

[seloumi]

@u-fischer I have updated my question

[FrankMittelbach]

somehow the \hspace is not generating a breakpoint which is suprising but I haven't looked why. It does break if you add an explicit breakpoint though, e.g. \allowbreak\hspace{5pt}.
I don't understand enough of the workings of direction changes but it looks as if

.\enddir TLT
.\glue 5.0
.\begindir TLT

is not allowing a break at the glue, ie the direction change preventing the glue from being seens as the "first glue in a sequence". That may be documented somewhere, but perhaps this is actually an engine bug.

[jbezos]

It’s wrong with bidi=default, too, so it could be indeed an engine bug.

[Udi-Fogiel]

This is not a bug, but a feature. See section 3.3.3 of LuaTeX's manual (Controlling glue with \breakafterdirmode):

\breakafterdirmode=1

\documentclass{article}
\usepackage{tikz}

\usepackage[bidi=basic,arabic,provide=*,layout=graphics]{babel}

\parindent=0pt

\newcommand{\tikzcircle}{\tikz[baseline=-0.5ex]{\node[draw=red,circle,minimum width=2em,align=center] at (0,0) {1};}\hspace{5pt}}

\begin{document}
	
	\foreach \x in {1,...,30}{%
		\tikzcircle
	}%
	
\end{document}

[jbezos]

@Udi-Fogiel Thank you. Because of the way bidi works in babel, very likely this ‘mode’ must be set to 1. I’ll investigate.

[jbezos]

@Udi-Fogiel After investigating a bit further, I still think it’s a bug or at least a misfeature. Some\...mode parameters are used to fix bugs without breaking old code. I reported a couple of bugs (or misfeatures) which are only fixed if you change the corresponding \...mode (eg, \matheqdirmode).

[Udi-Fogiel]

@jbezos You are probably right. I did not noticed they fixed the spacing problem around displayed math (with \matheqdirmode), thank you for pointing that out!

If this mode was added for backwards compatibility, should babel just set this to 1? couldn't that change the output of old documents? personally, I think that it should, but I know that LaTeX users often take high value for backwards compatibility.

Sorry if this is not the correct place to discuss this. But, discussing about bugs in LuaTeX's directionality and their fix, I've noticed there is weird behavior for \leqno and \eqno when \pardir and \textdir are differ from \pagedir and \bodydir. Is there some mode that fix that?

I've noticed that with babel the problem does not really exists, so I was wondering how did you deal with that.

[jbezos]

@Udi-Fogiel I think a bug or even a clearly counter-intuitive behavior should be fixed. This wouldn’t be the first time babel introduces such a change (and \matheqdirmode is an example).

Dealing with intrinsically ‘mixed’ stuff (graphics, math and tabular) is not trivial, because we I can’t know what a box actually contains. See for example #221. Currently, standard LaTeX math is patched by babel to get the label positioning and the vertical space right (\matheqdirmode=1 fixes the vertical spacing, which by default is buggy).

babel keeps track of the direction in three ways: with the luatex/omega primitives, at the TeX level with some macros, and as an attribute in each node (Unicode requires in fact 3 directions for bidi, namely, L, R (Hebrew) and AL (Arabic)).