`flushright` isn't right in rtl paragraphs about latex2e

[FrankMittelbach]

That is an interesting question and I think one can argue in both ways. Question: Do think that the command \raggedright should also always produce paragraphs that are ragged on the right side (because it has "right" in its name) or should this command follow the behavior current setting of the \pardirection?

[jbezos]

In think the current behavior is correct. In the context of luatex, ‘left’ means ‘start’ and ‘right’ means ‘end’, not only here but also in lists, margins and the like.

[FrankMittelbach]

That would be my understanding too, but I wanted to hear from @Udi-Fogiel if he thinks that, say, \raggedright should mean ragged at the right, and not ragged at the end of the line in a situation like right-to-left typesetting. In my opinion it shouldn't and flushleft is really just an paragraph level application of the former.

[Udi-Fogiel]

Question: Do think that the command \raggedright should also always produce paragraphs that are ragged on the right side (because it has "right" in its name)

Yes, that is exactly my point.

In think the current behavior is correct. In the context of luatex, ‘left’ means ‘start’ and ‘right’ means ‘end’, not only here but also in lists, margins and the like.

I'm not sure how margins or lists are related. in LuaTeX there are four independent primitive registers to control the margins, in each state of \pagedir. Since they are independent this analogy is a bit problematic. For example consider the following file:

\pagedir TRT\bodydir TRT\pardir TRT\textdir TRT
\pageleftoffset=10cm
Hello!
\vfill\break
\pagerightoffset=10cm
Hello!
\bye

it is kind of a different situation than in \rightskip and \leftskip. The fact that in LaTeX the margins are reversed in rtl context is because of how LaTeX deals with margins, it does not use \hoffset, nor any of the analogousness primitives (and in fact i opened a bug about it as well :) ). In OpTeX for example, when you specify left margins of 3cm width, this is what you get, regardless of the page direction.

\fontfam[lm]
\margins/1 a4 (4,2,1,1)in

\pagedir TRT\bodydir TRT\textdir TRT\pardir TRT

\lipsum[1-2]
\vfill\break

\pagedir TLT\bodydir TLT\textdir TLT\pardir TLT
\lipsum[1-2]
 \bye

it is the same in ConTeXt:

\setupdirections[bidi=global,method=one]
\setupalign[r2l]
\setuplayout[
    width=fit,
    rightmargin=5cm,
    backspace=7cm,
]
\starttext
\input knuth
\vfill\break
\setupalign[l2r]
\input knuth
\stoptext

But in LaTeX:

\documentclass{article}
\usepackage[left=7cm,right=5cm]{geometry}
\usepackage{lipsum}
\begin{document}
\lipsum[1-2]
\newpage
\pagedir TRT\bodydir TRT
\lipsum[1-2]
\end{document}

My point is that right should mean right, not end or a start of something. If it should be a start of a line, then, in an ideal world it would be called a start of a line, crossing between these two subjects will only lead to confusion in my opinion.

Here is nice reference to a similar discussion, that might lead to more confusion than help. I agree here with Khaled that on the engine level it would be much nicer interface if the engine would switch directions by itself, but on a user level, it could be very frustrating for new users to try and get the margins they want, only to understand that they need to type ''right' instead of "left" in some setting, without it being documented anywhere.

[Udi-Fogiel]

Javier I just realized you probably meant \leftmargin and \rightmargin, so sorry for diverging from the topic, but it is related to my last point, it is OK when it is on the engine level, I wouldn't expect that new users would be more comfortable with such an interface.

Another relevant point is probably the way the bidi package handles such things. In XeTeX with bidi, raggedright means ragged at the right. For example, in the following, regardless if I use the option RTLdocument, I get the same output

\documentclass{article}
\usepackage[
RTLdocument % comment this line to compare
]{bidi}
\usepackage{lipsum}
\begin{document}
\begin{flushright}
\lipsum[1-7]
\end{flushright}
\end{document}

the bidi package is aware of that, see section 1.14 of the bidi documentation. The behavior in LuaTeX can be obtained in the macro level, it is just that it is not what the users of bidi would expect, the same goes for page margins...

[davidcarlisle]

while re-interpreting left and right to mean start and end in the writing direction is not without problems I suspect that it's the most feasible. The decision shouldn't be made about a single enviornment such as flushright we should as far as possible treat all commands the same way so flush comamnds l and r column types and \makebox arguments, \leftmark ... etc.

It seems to me the important feature of \raggedright is not that it is ragged at the right but that it aligns the text start and sets each line its natural length so leaving the trailing edge ragged, so (despite the name) it is not unreasonable that it produces a ragged left margin an a RTL context.

Note the page layout as set by geometry or similar are different: the page size is really set independent of writing direction and there left should mean left.

The older luatex list discussion you link to makes similar points (there's no clear answer here) but Khaled says at one point

My preference is to treat left and right as "start of the line" and "end of the line",

which was in relation to \leqno but still it shows that such a re-interpretation wouldn't be that surprising.

[Udi-Fogiel]

while re-interpreting left and right to mean start and end in the writing direction is not without problems I suspect that it's the most feasible. The decision shouldn't be made about a single enviornment such as flushright we should as far as possible treat all commands the same way so flush comamnds l and r column types and \makebox arguments, \leftmark ... etc.

Than why the bidi package hasn't done that? I don't believe it is because it would complicate the code, but because it is the common preference among people who write in right to left.

Note the page layout as set by geometry or similar are different: the page size is really set independent of writing direction and there left should mean left.

The older luatex list discussion you link to makes similar points (there's no clear answer here) but Khaled says at one point

My preference is to treat left and right as "start of the line" and "end of the line",

Yes, in the context of how engine works I think this is the correct way, otherwise you end up patching many packages, as with bidi. But in the user interface it should not happen.

which was in relation to \leqno but still it shows that such a re-interpretation wouldn't be that surprising.

Consider how babel is currently treat that. It actually always put the equation numbers to the right, unless the leqno option is used, regardless of the main language direction

\documentclass[leqno]{article}
\usepackage[bidi=basic,hebrew,provide=*]{babel}
\usepackage{amsmath}
\begin{document}
\begin{equation}
1+2=3
\end{equation}
\end{document}

[Udi-Fogiel]

Consider how babel is currently treat that. It actually always put the equation numbers to the right, unless the leqno option is used, regardless of the main language direction

\documentclass[leqno]{article}
\usepackage[bidi=basic,hebrew,provide=*]{babel}
\usepackage{amsmath}
\begin{document}
\begin{equation}
1+2=3
\end{equation}
\end{document}

This is despite the fact the in LuaTeX the equation number position is usually depends on the value of \pardir. It is one thing how the engine behaves, and what the user interface should be, in my opinion.

[jbezos]

xetex, unlike luatex, just lacks a true bidi model and most of things are done by hacking lots of macros. I don't see it as an example to follow (on the contrary). As to math, note it’s always LTR even in RTL text (well, not always, but in most modern texts it is), so I don’t think it’s the same case.

But consider names like \leftmark, \leftmargin or \rightmargin. Remember also luatex reverses most of text, which means packages like titlesec should rename their macros depending on the direction, too. This would lead, imo, to a terminological mess.

Sticking to (and even enforcing) the luatex convention (‘left’ = ‘start’, ‘right’ = ‘end’) in text (I exclude math and graphics) is, I think, clearer and safer.

[David] Note the page layout as set by geometry or similar are different:

Actually, babel reverses page margins, too, so that a class (or margins as set by geometry) can be used without changes for English and Arabic documents. This applies, by the way, to a class or a package defining, say, quote with \raggedright; clearly in these cases right means end.

[Udi-Fogiel]

xetex, unlike luatex, just lacks a true bidi model and most of things are done by hacking lots of macros. I don't see it as an example to follow (on the contrary).

Yes, I agree that LuaTeX has a much nicer bidi model, but it doesn't really contradict what I was writing (or at least tried to convey). What bothers me is the user interface, not what happens behind the scenes.

I mentioned the bidi package because I think we can infer from it what would people expect from commands having right in their name, at the user level. For example it defines a command that behaves just like \raggedright in LuaTeX called \bidi@raggedleft, so the fact that \raggedright is the way it is in bidi is not really related to the limitations of the TeX--XeT model, but to the preference of the users.

I opened this ticket after some of the book writers were confused when we transitioned to LuaTeX. I also discussed it with several students and lecturers and about all expect that a command that contains the word right explicitly would place things to the right, regardless of other parameters.

As to math, note it’s always LTR even in RTL text (well, not always, but in most modern texts it is), so I don’t think it’s the same case.

As a student of mathematics in Tel-Aviv university in Israel, and as someone who works part time in a small publishing company for math books in Hebrew for the Open university in Israel, I'm some what aware of the conventions :)

I always thought of equation numbers as part of the paragraph, not part of the equation, I don't think the directionality of the equation should influence the location of the number (see also https://www.mail-archive.com/[email protected]/msg01420.html), and from what we can see, \eqno is affected from \pardir, so in the engine level the situation is not really different.

But consider names like \leftmark, \leftmargin or \rightmargin. Remember also luatex reverses most of text, which means packages like titlesec should rename their macros depending on the direction, too. This would lead, imo, to a terminological mess.

Sticking to (and even enforcing) the luatex convention (‘left’ = ‘start’, ‘right’ = ‘end’) in text (I exclude math and graphics) is, I think, clearer and safer.

My only argument was about the expectations of the average user (at least in my experience). For example when Frank asked if I would expect from \raggedright from always producing paragraphs that are ragged to the right, the answer is yes.

I completely agree that if changing the naming convention of macros will lead to an unnecessary complex code, then things should stay as they are, but it shouldn't imply what people would expect.

Actually, babel reverses page margins, too, so that a class (or margins as set by geometry) can be used without changes for English and Arabic documents.

@jbezos Can you clarify that? I don't think I follow. With the following example I get two different results with LuaLaTeX and XeLaTeX (which is somewhat annoying)

\documentclass[english]{article}
\usepackage[right=10cm]{geometry}
\ifluatex
\usepackage[bidi=basic,hebrew,provide=*]{babel}
\else
\usepackage[bidi=bidi,hebrew,provide=*]{babel}
\fi
\begin{document}
Hello
\end{document}

I don't see any reference in babel's documentation or code for the geometry package, nor to page margins, but there is a high possibility I missed some option.

I think the output with XeLaTeX is the correct one (and I think this is what people would expect), as with all other examples shown.

[u-fischer]

For example when Frank asked if I would expect from \raggedright from always producing paragraphs that are ragged to the right, the answer is yes.

I quite agree that the name of the command is confusing in a bidi context. But if we would redefine \raggedright so that it is means \raggedend in TLT and \raggedstart in TRT we would imho break various classes, packages and document commands which simply do not expect that. Quite apart from the fact that it would make the command more complicated as it would have to check directions (and I have no idea how to define it so that it behaves "correctly" if directions changes while \raggedright is already in effect.)

So instead of changing the behaviour of \raggedright I would suggest to define new user commands which are clearer:

\documentclass{article}

\usepackage{lipsum}
\NewCommandCopy\raggedend\raggedright
\NewCommandCopy\raggedstart\raggedleft
\begin{document}
\parindent=0pt
\raggedend 

\pardirection=1 \textdirection=1
\lipsum[1]

\pardirection=0 \textdirection=0
\lipsum[1]

\raggedstart
\pardirection=1 \textdirection=1
\lipsum[1]

\pardirection=0 \textdirection=0
\lipsum[1]

\end{document}

\usepackage[right=10cm]{geometry}

This looks wrong. And if I use book class (or twoside), then xetex doesn't look right either. But I'm not sure if babel or geometry is to blame.

[Udi-Fogiel]

So instead of changing the behaviour of \raggedright I would suggest to define new user commands which are clearer:

That is a great suggestion. Could these commands be added to the LaTeX format?

\usepackage[right=10cm]{geometry}

This looks wrong. And if I use book class (or twoside), then xetex doesn't look right either. But I'm not sure if babel or geometry is to blame.

According to the geometry documentation, the options left and right means inner and outer in two sided documents. In RTL books, the first page is usually on the left side, hence in our case right, which means outer, is on the left side, or at least I think this is the reason for the output with book class.

[jbezos]

\documentclass[english]{article}
%% Let’s assume there is a class with the following settings:
\usepackage[left=5cm]{geometry}
\usepackage{titlesec}
\titlespacing{\section}{-2cm}{1em}{1em}
%%
\usepackage{lipsum}
\ifluatex
\usepackage[bidi=basic,hebrew,provide=*]{babel}
\else
\usepackage[bidi=bidi,hebrew,provide=*]{babel}
\fi
\begin{document}
\section*{A section title}
\lipsum[1]
\section*{A section title}
\lipsum[1]
\end{document}

---

With english (ie, without loading hebrew):

With hebrew and luatex

With hebrew and xetex

Clearly, the layout in xetex is wrong. You won’t find any code in babel for geometry or titlesec, because luatex has a true bidi model (although not perfect) and (most) things are correctly placed out the box. xetex just doesn’t.

As to math, I’m willing to add a switch to set the exact behavior wrt \eqno and \leqno (not sure how difficult it can be, yet).