kvafa / bidi

Bidirectional typesetting in plain TeX and LaTeX, using XeTeX
https://ctan.org/pkg/bidi
6 stars 1 forks source link

bidi causes duplicated @-expressions in longtable #41

Open logological opened 3 months ago

logological commented 3 months ago

Brief outline of the issue

With a recent (2024-06-01-ish) release of LaTeX, use of the bidi package in conjunction with the memoir class causes the @-expressions of longtable environments to be printed extraneously. It seems that using a \multicolumn command is necessary to trigger the bug.

According to the discussion at Issue latex3/latex2e#1368, this may be because the array package, whose definitions bidi redefines, was recently changed.

I can reproduce the problem only with memoir; the standard article and book classes seem to be unaffected.

Check/indicate

Minimal example showing the issue

\documentclass{memoir}
\usepackage{longtable}
\usepackage{bidi}
\begin{document}

\begin{longtable}{l}
\multicolumn{1}{c}{foo} \\
\end{longtable}

\begin{longtable}{r@{x}l@{x}r@{x}l@{x}r@{x}l}
a & b & c & d & e & f \\
\end{longtable}
\end{document}

Expected behavior

The second longtable environment should print something like the following:

axbxcxdxexf

Instead it prints the following:

axbxcxdxexf x

Log and PDF files

test.log test.pdf

logological commented 3 months ago

I've reported the problem to the memoir class maintainer. They responded that it's not a memoir problem but rather an interaction between bidi and array (the latter of which memoir preloads, but the standard article class does not). So here's an alternative minimal example that uses article:

\documentclass{article}
\usepackage{array}
\usepackage{longtable}
\usepackage{bidi}

\begin{document}
\begin{longtable}{l}
\multicolumn{1}{c}{foo} \\
\end{longtable}

\begin{longtable}{r@{x}l@{x}r@{x}l@{x}r@{x}l}
a & b & c & d & e & f \\
\end{longtable}
\end{document}

test.pdf test.log

logological commented 3 months ago

With the latest release of array (2.6d on 2024-06-14) the problem is no longer reproducible. However, the discussion in latex3/latex2e#1368 suggests that the root of the problem is bidi's redefinition of internal things from array, and so it might be better if bidi were eventually updated to play nice with the new definitions.