When the following piece of LaTeX code. When it is processed by the xelatex, the resulting PDF file (attached to this ticket as "bidi.pdf") shows four lines of text.
The first line is meant to visualize the length of the text area, as well as its start and end points. Beyond these points, to the left and to the right, are the left and right margins, respectively.
The second and third lines of text are considerably shorter than the length of the text area. They are properly indented 3cm left of the right margin. These lines are meant to show that as long as a line's length is sufficiently short so that the indentation does not cause it to exceed the text area, the indentation works as expected.
The fourth line demonstrates the bug. It is as long as the text area itself. Despite the fact that the LaTeX code decrees that it should be indented 3cm like the previous two lines, it remains unindented. If it had been indented, it would exceed the text area, and its left edge would protrude into the left margin, which is the desired behavior.
It is also the expected behavior: when the bidi package is not loaded, the last line of text is indented by 3cm just like the previous two lines, and protrudes beyond the (right) margin, as seen in the attached file "nobidi.pdf".
\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}
I have ruled out the possibility that this is a bug with the bidi package, by submitting this issue to the bidi, resp. e-TeX, projects' bug tracking system. I received a reply from the bidi package's developer that the bug was not in bidi, but in the TeX--XeT algorithm that XeTeX uses via e-TeX. In fact, the above piece of code was suggested to me by the bidi developer, as my original demonstration was more complex than necessary.
I then reported this issue to the e-TeX project's bug tracking mailing list, and received the following reply from Mr. Lawrence Finstone.
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
Anonymous
This is not a XeTeX issue, it's the expected result of how the e-TeX right-to-left support works. For a simplified example, try
with plain pdf(e)tex.
This is essentially the same effect as you see in an example like
where, although the paragraph is right-to-left, the overfull lines are still flush with the left margin and project (and show their overfull markers) to the right, where a "truly right-to-left" system might be expected to reverse this.