Taco Hoekwater Wed, 19 Sep 2007 00:02:29 +0200 Eythan Weg wrote:

Hi,

Running this file under luatex 11.2 on amd64 fails, with "segmentation fault, probably due to infinite macro recursion".

---------------------- \pardir TLT \textdir TLT This is some text \textdir TRT and this is too.

\halign{% \textdir TLT #&\textdir TRT#\cr This and&that\cr}

Unfortunately this runs just fine on i386, so it will have to wait a while, until I have access to an amd64 installation again. Ok.

Also, it seems to me that eTeX treats alignment with directional instructions more sensibly:

--------------------- \TeXXeTstate=1 \halign{% \beginL#\endL&\beginR#\endR\cr This and&that\cr }

If you mean the syntax difference, that can be easily faked in luatex if you so desire, but I fail to see how that is more sensible: \protected\def\beginL{\bgroup\textdir TLT} \protected\def\endL{\egroup} % or \textdir TRT \protected\def\beginR{\bgroup\textdir TRT} \protected\def\endR{\egroup}% or \textdir TLT \newcount\TeXXeTstate % for completeness' sake Oh, I am sorry; I was not explicit: in the example I gave, LuaTeX typesets the word "that" right to left starting on the letter "d" of the word "and". Thus the letters "taht" overlaps the word "and". eTeX, on the other hand, typesets it like: "This andtaht". This latter behavior seems to me correct. Now I see that this might be a amd64 issue. Thank you, eythan

Taco Hoekwater writes:

You are right, this behaviour is unexpected. I am not sure if it can be fixed in a meaningful manner, I will look into that (Whatever else happens, I cannot go back to the eTeX bidi subsystem, because it simply is not powerful enough).

As a note aside, it has utterly weird side-effects too: if you have several \write statements (or specials or other whatsits, likely also marks and insertions) in one right-to-left line, they are processed left to right, which makes them rather ususable for getting information in reading order. TeX--XeT really is not useful for much more than short citations. -- David Kastrup

there should definitely be no overprint! when you write in Arabic you fill a box (from the R to the L) and then place the left border of that box on the current point. Having a result equivalent to the use of \llap makes no sense. Le 19 sept. 07 à 11h59, Taco Hoekwater a écrit :

Hi,

Taco Hoekwater wrote:

...

In the process of looking into it now, I did find some unreliability in te i386 executable, which possibly stems from the same bug as your crash.

Here is something weird: 'my' bug was a problem that happened only in \pdfoutput=1 mode, and it was very easy to fix. Eythan, if you were testing in pdf mode, this is likely the cause of the crashes on amd64, and the latest trunk will fix it. If you had crashes in dvi mode, my fix will do nothing for you.

I did run into something different that now needs to be resolved:

The pdf bidi output internals are quite different from the dvi ones, and I now get the to-be-expected output "This andtaht" (no overprint), but only in pdf mode. In dvi mode, there is still overprint, as in Aleph.

This confuses me a bit: I am now not sure which of the two outputs is 'officially' wrong. CC to Yannis, hoping he can tell me whether the dvi overprint is a bug or intended behaviour (I have attached the tex input and a pdf generated by Aleph).

Best wishes, Taco

-- +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis.haralambous@enst-bretagne.fr | | Directeur d'Études http://omega.enstb.org/yannis | | Tel. +33 (0)2.29.00.14.27 | | Fax +33 (0)2.29.00.12.82 | | Département Informatique | | École Nationale Supérieure des Télécommunications de Bretagne | | Technopôle de Brest Iroise, CS 83818, 29238 Brest CEDEX 3, France | | Coordonnées Google-Earth : 48°21'31.57"N 4°34'16.76"W | +--------------------------------------------------------------------+ ...pour distinguer l'extérieur d'un aquarium, mieux vaut n'être pas poisson ...the ball I threw while playing in the park has not yet reached the ground Es gab eine Zeit, wo ich nur ungern über Schubert sprechen, nur Nächtens den Bäumen und Sternen von ihm vorerzählen mögen.

Taco Hoekwater Wed, 19 Sep 2007 11:59:29 +0200 Hi, Taco Hoekwater wrote:

In the process of looking into it now, I did find some unreliability in te i386 executable, which possibly stems from the same bug as your crash.

Here is something weird: 'my' bug was a problem that happened only in \pdfoutput=1 mode, and it was very easy to fix. Eythan, if you were testing in pdf mode, this is likely the cause of the crashes on amd64, and the latest trunk will fix it. If you had crashes in dvi mode, my fix will do nothing for you. This snippet still crushes in either dvi or pdf mode: \pardir TRT \textdir TRT This is some text \textdir TLT and this is too. I did run into something different that now needs to be resolved: The pdf bidi output internals are quite different from the dvi ones, and I now get the to-be-expected output "This andtaht" (no overprint), but only in pdf mode. In dvi mode, there is still overprint, as in Aleph. Yes, this now works (no overprinting) also on amd64. This confuses me a bit: I am now not sure which of the two outputs is 'officially' wrong. CC to Yannis, hoping he can tell me whether the dvi overprint is a bug or intended behaviour (I have attached the tex input and a pdf generated by Aleph). Best wishes, Taco Thank you, eythan