# Wrong pdflastxpos value with XeLaTeX+bidi

The answer from Vala helped me to rephrase my question. See the original one below.

Using pdfsavepos to get absolute position of texts on the page, I faced the following problems when using XeLaTeX in right-to-left mode. The sample code

\documentclass{article}
\usepackage[paperwidth=20000000sp,paperheight=10000000sp,
hmargin=2000000sp,vmargin=1000000sp]{geometry}
\usepackage[enable,step=1000000sp,tr]{bidipagegrid}
\usepackage{bidi}
\begin{document}

\makeatletter
\def\where#1{\pdfsavepos\write-1{XPOS(#1)=\the\pdflastxpos}%
\if@RTL\immediate\write-1{XPOS(#1) is RTL}\fi\ignorespaces}
\makeatother

\noindent \where{A1}AA\where{A2}

\begin{itemize}
\item[\where{X1}X\where{X2}]
\hspace*{0pt}\where{D1}DtoD\where{D2}{} xxx \LR{x\where{E1}EtoE\where{E2}x}
\end{itemize}

\setRL

\noindent \where{B1}BB\where{B2}{} \LR{x\where{C1}CtoC\where{C2}x}

\begin{itemize}
\item[\where{Y1}Y\where{Y2}]
\hspace*{0pt}\where{G1}GtoG\where{G2}{} xxx \LR{x\where{H1}HtoH\where{H2}x}
\end{itemize}

\end{document}


outputs the following values in the log file:

XPOS(B1) is RTL  XPOS(B2) is RTL
XPOS(Y1) is RTL  XPOS(Y2) is RTL
XPOS(G1) is RTL  XPOS(G2) is RTL
XPOS(A1)=2,000,000 XPOS(A2)=2,983,042
XPOS(X1)=2,819,201 XPOS(X2)=3,310,722
XPOS(D1)=3,638,402 XPOS(D2)=5,222,192
XPOS(E1)=7,042,642 XPOS(E2)=8,517,206
XPOS(B1)=2,000,000 XPOS(B2)=2,928,430
XPOS(C1)=3,492,769 XPOS(C2)=5,021,945
XPOS(Y1)=1,180,799 XPOS(Y2)=1,672,320
XPOS(G1)=2,000,000 XPOS(G2)=3,611,096
XPOS(H1)=5,431,546 XPOS(H2)=6,997,132


and produces the following page (grid step is 1,000,000sp):

I would like to know the marked positions on the page. This seems easy for A, X, D, E (all in LTR mode) and even B (B is RTL so counting from the right), but I have questions for C (LTR text but measured from the right, and C1 and C2 are switched), G (seem to be shifted) and H (both shifted and switched). Could anybody help me to get absolute positions from pdflastposx output?

Original question, for reference.

The following code gives wrong X location values for the right-to-left writing part (B).

\documentclass{article}
\usepackage{bidi}
\begin{document}
\makeatletter
\def\where#1{\pdfsavepos\write-1{XPOS(#1)=\the\pdflastxpos}%
\if@RTL\immediate\write-1{XPOS(#1) is RTL}\fi\ignorespaces}
\makeatother

\where{A0} First \where{A1} line here in RTL mode...

\setRL

\where{B0} Second \where{B1} one \LR{h\where{B2}er\where{B3}e}

\end{document}


It seems that some of these X values increase from right to left: the log file gets

XPOS(B0) is RTL
XPOS(B1) is RTL
XPOS(A0)=8799518
XPOS(A1)=11380911
XPOS(B0)=8799518
XPOS(B1)=12003504
XPOS(B2)=13569089
XPOS(B3)=14117043


But I think we should have A0 < A1 < B2 < B3 < B1 < B0 (if looking at the PDF). Could anybody give me a clue to get the right values?

Note that with an old version of texlive (2012-06-11 from debian squeeze), I get

XPOS(B0) is RTL
XPOS(B1) is RTL
XPOS(A0)=8799518
XPOS(A1)=11380911
XPOS(B0)=8799518
XPOS(B2)=26164732
XPOS(B3)=26712686
XPOS(B1)=26712686


with the same resulting PDF.

The following code gives wrong X location values for the right-to-left writing part (B).

No, it is not wrong.

It seems that some of these X values increase from right to left.

That is what it should be.

But I think we should have A0 < A1 < B2 < B3 < B1 < B0 (if looking at the PDF).

No, you are wrong. When you are in LTR mode, the x coordinate of the reference point is on the left hand side of the pdf (where the line starts) and when you are in RTL mode, the x coordinate of the reference point is on the right hand side of the pdf (where the line starts) and that is completely ok and logical.

Indeed, you should have A0=B0, A1~=B1 and A0 < A1 < B2 < B3 and that is what you have.

Could anybody give me a clue to get the right values?

It gives you already the right values. Anyways, bidi package has nothing to do with this. This all happens at the engine level.

• Welcome to TeX.SX! Would you care to comment on the old values from texlive 2012 that the poster mentions? – Andrew Swann Nov 11 '14 at 8:05
• @AndrewSwann: I have no idea. Sorry. As I said it all happens at the engine level so perhaps the behavior of xetex engine was modified somehow. The bidi package does not even touch \pdfsavepos and \pdflastxpos primitives. – Vafa Khalighi Nov 11 '14 at 8:08
• And what about B2 and B3? We do have B2<B3 as a LTR text, but the values refer to distance from the right side of the page. If we consider B2 and B3 as distance from the left side of the page, the values are wrong, but if we consider B2 and B3 as distances from the right side of the page, the values are swapped. – Jojo Boulix Nov 11 '14 at 14:13
• @JojoBoulix: I see that but even then that is engine bug since bidi has nothing to do with this. This arises in a number of other scenarios, for example try two consecutive \label one immediate after the other and then look at the .aux file, you will see that the order is reversed. This is TeX--XeT bug. – Vafa Khalighi Nov 11 '14 at 16:35
• I believe, Khaled Hosny has fixed it in the engine. Can you build xetex and xdvipdfmx from source and try to see if it is fixed or not? – Vafa Khalighi Nov 11 '14 at 16:35