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:
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:
However, here's what the file actually displayed as when opened in a PDF viewer:
Why isn't the distance of the lower rectangle from the right margin as specified, namely 3cm? How can this be fixed?
Remarks
- I have filed a bug report about this issue with the Polyglossia project.
- 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}
So I have filed a bug report with the bidi project.
- 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.
- After notifying the developer of the
bidipackage that I had submitted a bug report to thee-TeXproject, 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.
- 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.
- 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.





babelto work. When I replace the\iffalse ... \ficode by the following:\usepackage[utf8x]{inputenc} \usepackage[english,hebrew]{babel}, compilations withpdflatexandxelatexfail, whereas compilation withlualatexseems not to end. – Evan Aad Nov 12 '22 at 06:26babelfor 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:25lualatex, 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:57babelandluatex, try adding the optionlayout=graphicswhen loading the package (something like\usepackage[bidi=basic, layout=graphics]{babel}). See the manual for further info. – Javier Bezos Nov 18 '22 at 06:46bidi+xetex, but about a previous comment related tobabel. At least, your MWE works as expected with the latter andluatex. – Javier Bezos Nov 18 '22 at 09:33babel+lualatex, in large part due to your energetic involvement on this site. – Evan Aad Nov 18 '22 at 09:36