>> It shouldn't harm to load babel before the user preamble, I even
>> think this is an advantage because many packages need the loaded
>> babel for translations and the users are able to change babel
>> translation.
>
> A typical example, cited in bug 315, is
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg34407.html
> [see section 6]
The problem in
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg34407.html
is about the cite-package that can be load by loading babel again after his package in the
user-defined preamble. And I think with newer versions of cite this problem has gone.
> I have always taken it for granted that babel should be the last
> package, maybe with the exception of hyperref.
I still haven't seen an example where that prooves this. And note that now babel is loaded after all
required packages, but before the user-defined preamble. That means there can only be problems with
packages users load manually.
But anyway, please send me an example file where this doesn't work and I'll
adapt BufferParams.cpp.
hyperref works fine when babel is loaded behind it, this is proven by many LyXers that used hyperref
in their preamble. I asked Heiko Oberdiek, the hyperref maintainer, where to load it best and he
frecommended to load hyperref before babel anyway.
So reverting my change wouldn't be a problem, but:
> I cannot find another
> link to this assertion, but found this file, which explains why I was
> afraid of supporting hyperref :)
> http://www.ctan.org/tex-archive/macros/latex/contrib/hyperref/README
jurabib also has to be loaded behind babel, that's why we have a hck in
Bufferparams.cpp that does this.
But anyway what is the problem with the cases described in?:
http://www.ctan.org/tex-archive/macros/latex/contrib/hyperref/README
Here's a list with potential problematic packages:
algorithm
---------
\usepackage{float}
\usepackage{hyperref}
\usepackage[chapter]{algorithm}% eg.
No problem as long as the algorithm float definition is behind hyperref. And that's what we
currently have.
amsmath
-------
The environments equation and eqnarray are not supported too well.
For example, there can be spacing problems. Consider using the
environments that package amsmath provide, e.g. gather for equation.
The environment equation can even redefined to use gather:
\usepackage{amsmath}
\let\equation\gather
\let\endequation\endgather
I can't see a problem. I use hyperref in my German math manual that uses eqnarray as well as all
possible amsmath constructs and it works fine.
amsrefs
-------
Package loading order:
\usepackage{hyperref}
\usepackage{amsrefs}
We don't use amsrefs. When the user loads it manually it would be behind hyperref. When we once plan
to support amsrefs, we load it behinf hyperref in Bufferparams.cpp
babel/magyar.ldf
----------------
Unsupported.
magyar.ldf's redefinitions of many LaTeX internals conflict
with hyperref's redefinitions of these commands.
This is a bug in babel, but the maintainer of babel don't maintain it :-(. There is a correct
magyar.ldf available and heiko is trying to get it into babel. I'll add a hin to the docs that
magyar users should deactivate hyperref or use hungarian.ldf.
bibentry
--------
easyeqn
-------
When the users loads this, he should know about the hyperref incompatibility
and turn of hyperref.
cite
----
I think cite has been updated in the meantime.
foiltex
-------
The user can add the workaround to the preamble, or they can turn of hyperref.
footnote
--------
You can use the corresponding hyperref option.
multind
-------
titleref
--------
User has to turn of hyperref. And load it manually in the preamble.
nomencl
-------
preamble hacks can be applied, but are only needed when you want to have the page numbers clickable
in the nomenclature.
subfigure
---------
Works with the latest version.
vietnam
-------
I'll take care of this when I eventually add vietnamese support.
---------
But anyway hyperref support doesn't harm in any case since you can choose to use it or not. When you
are manually loading a special package you should have read its documentation.
>> Those who don't learn from history are condemned to repeat it.
>
> I would not be so harsh, but such change necessitates a lot of care
> and should not have been done without prior discussion.
Hmm, we agreed to put the hyperref stuff in and I take care of the correct loading position.
Therefoer I contacted Heiko and goggled the lists.
Now everybody can test if there are problems, and if so we can program
something for BufferParams.cpp.
regards Uwe
