Making polyglossia and zref-savepos or pdfsavepos work together

When I add the polyglossia package to use my Hebrew text, it breaks the writing of the coordinates to a file. If I remove the polyglossia package it works fine. Not sure if it is related to zref. And if you add a \newline in between each line it works fine, but I need the text to flow as a paragraph.

MWE:

\documentclass{article}%
\usepackage{zref-savepos}%

\usepackage{polyglossia}%
\setmainlanguage{hebrew}%
\setotherlanguage{english}%

\defaultfontfeatures{Mapping=tex-text}
\setmainfont{Times New Roman}
\newfontfamily\hebrewfont[Script=Hebrew]{Times New Roman}
\newfontfamily\hebrewfontsf[Script=Hebrew]{Times New Roman}

\AtBeginDocument{%
\newwrite\myoutputfile%
\openout\myoutputfile=\jobname.yposout.txt%
}
\AtEndDocument{%
\closeout\myoutputfile%
}

\def\mywriting#1{%
\zsaveposy{#1}%
\typeout{#1:\zposy{#1}}% Write to log file to double check.
\write\myoutputfile{#1:\zposy{#1}}%
}%

\newcommand\writingpos[2][]{%
\mywriting{#2}%
}%

\begin{document}%
\begin{hebrew}
\writingpos{40001001} This is my very long sentence which spans a line or so and it's Y-position at the beginning will certainly have to be different from it's Y-position at the end of this line and I'll use it to test the output of the ZREF package.\writingpos{40001001L}
\writingpos{40001002} This is my SECOND very long sentence which spans a line or so and it's Y-position at the beginning will certainly have to be different from it's Y-position at the end of this line and I'll use it to test the output of the ZREF package.\writingpos{40001002L}
\writingpos{40001003} This is my THIRD very long sentence which spans a line or so and it's Y-position at the beginning will certainly have to be different from it's Y-position at the end of this line and I'll use it to test the output of the ZREF package.\writingpos{40001003L}
\end{hebrew}
\end{document}%


The log file shows this (which is correct):

40001001:42747166
40001001L:40518942
40001002:40518942
40001002L:38159646
40001003:38159646
40001003L:36586782


But the output file gives this (which is incorrect):

40001001:42747166
40001002:40518942
40001001L:40518942
40001003:38159646
40001002L:38159646
40001003L:36586782


Notice the difference in the order of the first numbers (ID). It should follow on such as ...001, ...001L, ...002, ...002L, ...003, ...003L etc.

-
It's not polyglossia but bidi: You can the same result if you use simply a RTL-environment (I don't know what happening exactly - I do find bidi confusing). But as far as I can see only the order in the output file is changed, the values themselves are correct, so where is your problem? –  Ulrike Fischer Sep 3 '13 at 15:34
@UlrikeFischer I really needed to understand whether this order would stay consistent, I guess. Because then I can take it into account when I develop my parser bit of the code. –  McGafter Sep 4 '13 at 7:23
@UlrikeFischer It is a bit strange though that it is messing about with the first set of numbers while leaving the actual y-pos values in their correct place. Is there a way of easily rectifying this? Otherwise I'll have to externally split the two sets then sort the values and then put them back together again, I guess. –  McGafter Sep 4 '13 at 7:28
Well if you add \fbox{#1} to your \writingpos command you can see that the values are writting simply in "normal" LTR-mode: From top to bottom and left to right (perhaps only because at shipout LTR is active). This means that you can't know the order before the compilation as you don't know which commands will be in the same line. Why does your parser need the order? Why doesn't it simply check the names like the standard \label/\ref system? –  Ulrike Fischer Sep 4 '13 at 7:50
@UlrikeFischer I'm not sure I understand your reference to \label/\ref but each y-pos "42747166" gets associated to a unique ID "40001001", but if they get "swapped around" then it is of no use when I parse them on the next run. –  McGafter Sep 4 '13 at 9:36

There is a difference in the way luatex and xetex handle writes in a RTL context.

With luatex you get

40001001:43889459
40001001L:41661235
40001002:41661235
40001002L:39301939
40001003:39301939
40001003L:37729075


with xetex you get

40001001:42747166
40001002:40518942
40001001L:40518942
40001003:38159646
40001002L:38159646
40001003L:36586782


Note the order is different (the numbers are different too as the origin is slightly different)

-
It is a bit strange though that it is messing about with the first set of numbers while leaving the actual y-pos values in their correct place. Is there a way of easily rectifying this? Otherwise I'll have to externally split the two sets then sort the values and then put them back together again, I guess. –  McGafter Sep 4 '13 at 7:26
@McGafter It doesn't mess around with them really it just handles the direction switch after rather than before writing, it is an issue of whether writes occur in the order in the file or in the visual display order, If you think of the display as left to right then these differ in RTL sections. –  David Carlisle Sep 4 '13 at 8:11
Thanks I've figured out the pattern of it now and what's happening. –  McGafter Sep 4 '13 at 9:54