Provide check to allow document classes to declare themselves bidi-aware
There should be a way for a document class to indicate to bidi that they do not need bidi to redefine things for R-L support. This often results in unexpected behavior, as indicated in the tex.se links below. Perhaps the most egregious is that a document class that builds on any of the common document classes might see its formatting overwritten because of, e.g., a few passages of Hebrew, Arabic or Persian that appear in the document.
\thesection should not be modified by bidi. Perhaps by doing something like
\providecommand{\@bidiawareclass}{}
and then having bidi do a check with
\ifdef\@bidiawareclass
\else
all the redefinitions for assorted classes go here
\fi
or alternatively, using some mechanism like etoolbox's \patchcmd and/or the newer LaTeX hooks would be a more robust way of effecting changes without necessarily damaging existing document classes. If you're open to it, I'd be willing to do a proper PR for some of that code.
Provide check to allow document classes to declare themselves bidi-aware
There should be a way for a document class to indicate to
bidithat they do not needbidito redefine things for R-L support. This often results in unexpected behavior, as indicated in the tex.se links below. Perhaps the most egregious is that a document class that builds on any of the common document classes might see its formatting overwritten because of, e.g., a few passages of Hebrew, Arabic or Persian that appear in the document.Check/indicate
xepersianpackagexepersianpackage issue tracker has been searched for similar issues?https://tex.stackexchange.com/questions/596977/best-practice-for-dealing-with-bidis-redefinitions-for-class-authors https://tex.stackexchange.com/questions/602037/titlesec-package-not-suppressing-chapter-number-from-section-in-xelatex
Minimal example
does not apply, exactly, but here's an minimal version of a document class that might find itself affected:
Expected behavior
\thesectionshould not be modified bybidi. Perhaps by doing something likeand then having
bidido a check withor alternatively, using some mechanism like
etoolbox's\patchcmdand/or the newer LaTeX hooks would be a more robust way of effecting changes without necessarily damaging existing document classes. If you're open to it, I'd be willing to do a proper PR for some of that code.