1

The following LaTeX code is saved in the file ~\test.tex:

\documentclass{article}
\usepackage{lipsum,tikz}
\usetikzlibrary{fit}

\iffalse \usepackage{polyglossia} \setmainlanguage{hebrew} \setmainfont{Arial} \fi \begin{document} \lipsum[1-1]

\noindent\hspace{0cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};

\noindent\hspace{3cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {}; \end{document}

When the following commands are executed in the Terminal:

cd ~
pdflatex test

a PDF file is generated at the path ~\test.tex. When opened in a PDF viewer, the file displays as follows:

Without polyglossia

If now the two lines containing \iffalse and \fi are commented, and the command xelatex test (rather than pdflatex test) is run, a new PDF file is generated at the path ~/test.pdf. Here's what I expected to see when the file were opened in a PDF viewer, essentially a horizontal mirror image of the version shown above:

Expected outcome

However, here's what the file actually displayed as when opened in a PDF viewer:

With polyglossia

Why isn't the distance of the lower rectangle from the right margin as specified, namely 3cm? How can this be fixed?


Remarks

  1. I have filed a bug report about this issue with the Polyglossia project.
  2. Jürgen Spitzmüller from the Polyglossia project looked into my bug report and replied:

As shown by the following example, this is not a bug in polyglossia, but a bug in bidi. So please file a ticket at kvafa/bidi/issues

    \documentclass{article}
    \usepackage{lipsum,tikz}
    \usetikzlibrary{fit}
\usepackage[RTLdocument]{bidi}

\begin{document}
  \lipsum[1-1]

  \noindent\hspace{0cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};

  \noindent\hspace{3cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};
\end{document}

A bug in the bidi package.

So I have filed a bug report with the bidi project.

  1. I have received the following reply from the developer of the bidi package.

I have looked into this and it seems to be a limitation of the TeX--XeT algorithm that XeTeX uses via e-TeX. To see the issue independent of tikz, please see the following minimal example:

\documentclass{article}
\usepackage[RTLdocument]{bidi}
\begin{document}
\noindent\hbox{This horizontal box should contain enough text so that its width is the same a}

\noindent\hspace{3cm}\hbox{This horizontal box should contain}

\noindent\hspace{3cm}\hbox{This horizontal box should contain enough text so that}

\noindent\hspace{3cm}\hbox{This horizontal box should contain enough text so that its width is the same a} \end{document}

where you should see the same behavior. As this is an engine bug/limitation, I am afraid that there is not much I can do here. However, if you just want to get the same output, something like the following should do the trick.

\documentclass{article}
\usepackage{lipsum,tikz}
\usetikzlibrary{fit}

\usepackage[RTLdocument]{bidi}

\begin{document} \lipsum[1-1]

\noindent\hspace{0cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};

\moveleft\dimexpr3cm-\parindent\relax\hbox{\tikz \node [ draw, fit={(0,0) (12,1)} ] {};} \end{document}

Please note that I certainly acknowledge that this is a bug but as it is the engine issue, I do not think there is much that I can do at the level of the bidi package. Sorry!

So I have filed a bug report with the e-TeX project.

  1. After notifying the developer of the bidi package that I had submitted a bug report to the e-TeX project, as per their recommendation, I received a further communication from them, as follows.

The original author of e-TeX passed away several years ago sadly and I think it is quite unlikely that this gets fixed any time soon if at all. The workarounds that I suggested are not too bad so I think they should work.

  1. I have received the following message from Laurence Finston of the e-TeX bug tracking mailing list.

I've tested this a little more and discovered that \parindent and \beginR ... \leftR don't work well together. With the following example, if you set, e.g., \parindent=1cm, you get an overfull box in the second block of text.

Depending on what you want, it may be advisable to put the r-to-l text in a vbox. In the first block, the last, incomplete line is typeset flush left, not flush right. In the second block, it is flush right, which is probably the desired behavior.

If one wants indentation, it's best to put explicit glue at the beginning of a paragraph or line in r-to-l mode, i.e., a skip or a kern. It would seem that r-to-l mode is really designed for short passages within l-to-r text and not for full paragraphs or multiple paragraphs. It can be used for those things, but it takes a little extra work.

\beginR
The quick brown fox jumps over the lazy dog.  The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.  The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.  The quick brown fox jumps over the lazy dog.
\endR

\vskip1cm

\beginR \vbox{\leavevmode The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. } \endR

So I have filed a bug report with the XeTeX project.

  1. I have conveyed Mr. Finston's remarks to the developer of the bidi package, and have received the following reply (which I have edited slightly to make it less personal).

the issue is not that we can not place an \hbox wherever we like but explicitly the one demonstrated in my code above. Sure, we can place an \hbox wherever we want to place as shown in my two other solutions but he entirely misses the point. I am also a Plain TeX user and do not use LaTeX. All one has to do is apply the content of the minimal example I provided in right to left in Plain TeX and see the issue for oneself.

Having said that, I was in contact with Peter Breitenlohner, the original author of e-TeX several years ago when he was still alive and we discussed several issues including this one. He agreed back then that this was a limitation of TeX--XeT algorithm in e-TeX and that it could be a feature since \beginL, \endL, \beginR, and \endR are all horizontal primitives. We agreed that this could be fixed and Peter said that he will work on it but sadly he passed away and things were not fixed. In fact, if you look at TeXLive commits, you can see some of the history of our discussions.

Evan Aad
  • 11,066
  • 1
    @Zarko This is a different question than the previous one I asked. Whereas in the previous one I described a desired situation and asked how it can be accomplished, in this question I implement the answers given to the previous question, and show that in certain circumstances, namely in the presence of the polyglossia package for Hebrew, they fail. In other words, this question shows that in some cases that are of interest to me the answers given to the other question are ineffectual. – Evan Aad Nov 11 '22 at 19:13
  • 1
    You can avoid the problem by using babel instead of polyglossia. – samcarter_is_at_topanswers.xyz Nov 12 '22 at 00:13
  • @samcarter_is_at_topanswers.xyz I can't get babel to work. When I replace the \iffalse ... \fi code by the following: \usepackage[utf8x]{inputenc} \usepackage[english,hebrew]{babel}, compilations with pdflatex and xelatex fail, whereas compilation with lualatex seems not to end. – Evan Aad Nov 12 '22 at 06:26
  • @EvanAad See how to set up babel for Hebrew here: https://tex.stackexchange.com/a/561139/5735 , https://tex.stackexchange.com/a/620541/5735 . An external link is https://latex3.github.io/babel/guides/locale-hebrew.html . – Javier Bezos Nov 12 '22 at 07:25
  • @JavierBezos Thanks. I gave it a shot. Indeed with the code given in the first link you provided the document compiles successfully with lualatex, and a PDF file is generated, but the rectangles are drawn all wrong. It's a different kind of wrongness than polyglossia, but it's still all wrong. – Evan Aad Nov 12 '22 at 07:57
  • @EvanAad With babel and luatex, try adding the option layout=graphics when loading the package (something like \usepackage[bidi=basic, layout=graphics]{babel}). See the manual for further info. – Javier Bezos Nov 18 '22 at 06:46
  • @JavierBezos As Jürgen Spitzmüller's example indicates, the same buggy behavior occurs even when there are no graphics in the document, and when neither babel nor polyglossia are loaded. – Evan Aad Nov 18 '22 at 06:56
  • 1
    @EvanAad Sure, but my comment is not about bidi+xetex, but about a previous comment related to babel. At least, your MWE works as expected with the latter and luatex. – Javier Bezos Nov 18 '22 at 09:33
  • @JavierBezos I have since switched my current Hebrew project to use babel+lualatex, in large part due to your energetic involvement on this site. – Evan Aad Nov 18 '22 at 09:36

1 Answers1

2

Interestingly, geometry package's default setting is doing something that bidi can get a grip on:

with geometry

That is to say, the implication is that the bugfix should be straightforward to implement, I expect.

MWE

\documentclass{article}
\usepackage{geometry}

\usepackage{lipsum,tikz} \usetikzlibrary{fit}

\usepackage[RTLdocument]{bidi}

\begin{document} \lipsum[1-1]

\noindent\hspace{0cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};

\noindent\hspace{3cm}\tikz \node [ draw, fit={(0,0) (12,1)} ] {};

\end{document}

Cicada
  • 10,129
  • Not the case. Change 12 to 15 and see what happens. – Evan Aad Nov 13 '22 at 08:27
  • Yes, correct. geometry's interactions is pointing to something to do with (I guess, the negative?, or a null) involving one of the margins, so the implication remains. But this is not diagnosis, just speculation. – Cicada Nov 13 '22 at 10:08