Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

There is a problem when bidi & hyperref packages are used together and custom document style is used. For example:

\documentclass[unicode]{myreport}

\usepackage{xltxtra}

\author{Author}
\title{Title}

\usepackage[pagebackref=true, xetex, unicode]{hyperref}
\usepackage{bidi}

\begin{document}

\maketitle

Test

\end{document}

myreport class is the exact copy of standard report class (nothing is changed). Problem is in \maketitle command. Result:

! TeX capacity exceeded, sorry [input stack size=5000].
\@ifnextchar #1#2#3->\let \reserved@d =#1
                                         \def \reserved@a {#2}\def \reserved...
l.14 

This error doesn't occur when:

  1. hyperref package isn't used, or

  2. standard report class is uded, or

  3. \maketitle command isn't used

I can't find any information about such behavior neither in bidi nor in hyperref documentation, nor in google.

I see that bidi package uses command \@ifclassloaded and plugs files like report-xetex-bidi.def. Maybe such file should be created for custom docclass. But I saw this file and didn't find anything 'special' in it.

Bidi package is needed, since document will be multilingual with polyglossia and with some text in Arabic (and maybe other) language.

What can be done in this situation?

share|improve this question
    
I suspect that such behavior started since the last update, as I worked someway a week before. –  Basil Peace Jun 24 '12 at 19:35
    
Welcome to TeX.SX! There is something special in report-xetex-bidi.def: some commands, in particular \maketitle are redefined to cope with bidirectional input. A recommended practice is to \LoadClass{report} and do the desired modifications after this, instead of writing a class from scratch. –  egreg Jun 24 '12 at 23:08
    
Yes, \maketitle is redefined, but I don't see anything special in the redefined \maketitle. I see, that, if I don't use RTL characters in title page, all should work without redefinition. –  Basil Peace Jun 25 '12 at 7:16
    
Well, I do see special things in the redefined \maketitle which are important for allowing RTL in the title. –  egreg Jun 25 '12 at 7:28
    
This doesn't explain why hyperref package is involved. –  Basil Peace Jun 25 '12 at 9:57
show 1 more comment

1 Answer

I can not reproduce the problem if I create myreport.cls as:

\LoadClass{report}

\endinput

However if your myreport.cls is verbatim copy of report.cls, then the error you described follows. The best is to use \LoadClass and then doing your redefinitions as user @egreg explained. There are few changes to \maketitle in report-xetex.def. If you study the code clearly it is some changes with respect to footnote rule (\right@footnote, \left@footnote, and \textwidth@footnote) and some footnote commands (\footnote, \LTRfootnote, \RTLfootnote, \thanks, \LTRthanks, and \RTLthanks). Why this error happens with hyperref and why this is related to hyperref package? If you look at the hyperref package, there are some redefinitions of \maketitle, and the file hyperref-xetex-bidi.def redefines those changes of \maketitle that hyperref does to give you correct hyperlinks in RTL mode. First you load myreport.cls, so there is obviously a definition of \maketitle, then when you load hyperref, it does \let\HyOrg@maketitle\maketitle and then makes some changes to the \maketitle command; later you load bidi and because bidi needs to do some modification to hyperref, it also does \let\HyOrg@maketitle\maketitle and also some modifications to \maketitle, so obviously unless there is a redefinition of \maketitle before loading hyperref-xetex-bidi.def, you get a "TeX capacity exceeded" error.

Conclusion: As you can guess, things get complex and complicated so it is best to use \LoadClass and let the bidi package take care of issues automatically.

share|improve this answer
    
This appears to be similar to the problem with amsart that was reported here and subsequently fixed. But I guess there is no easy way to preempt the problem for every document class. –  Ari Brodsky Dec 23 '12 at 8:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.