Rasmus <ras...@gmx.us> writes: > Hi Carsten, > > Carsten Dominik <carsten.domi...@gmail.com> writes: > >>> Note: I should be obvious that I prefer to load as little stuff be >>> default as possible. That is: I'm biased, but it's OK when everyone >>> knows. >> >> Yes. Of course the cleanest solution would be to load as little >> as possible. But convenience and backward compatibility are >> also a concern which I would like to consider. > > I agree. And, as said, people who want a 'clean' solution (to his or > her mind) can easily get that. So convenience is certainly something > that should be considered! > >>>> - to add the rotating package >>>> - do document that the tabu package is needed when specifying tabu >>> >>> Note the package loading order might matter. >> >> Yes, I am aware of this. Can you be specific for this case? I guess >> rotating has no load sequence issues. > > I doubt rotating causes issues as it provides its own environments > cf. section 2.2 of its manual. I didn't find any reports on the > Internets. > >> Does tabu have such issues [of conflicting with other packages]? >> With which packages (what you know) > > I don't think tabu causes any problems. It states it doesn't rewrite > any existing code (as e.g. tabularx does) cf. p. 1. > > Perhaps, Eric Abrahamsen (Cc'ed) has more experience with tabu > (according to the log Eric added tabu support). > > Unfortunately, I haven't moved to tabu yet. Supposedly, it can > replace most other tabular packages including longtable and it's > compatible with many other packages cf. p. 9 of its manual (but that's > another story). >
There seems to be some concern about an unmaintained tabu package. See here, for a good summary of that: http://tex.stackexchange.com/a/121847/15392 - Andreas >>>> - do document that amsmath in needed when generating a matrix >>> >>> and subscripts. And sometimes math (e.g. align). >> >> amsmath is (edited) in the defualt list, patch by you IIRC. So we >> actually do not have to say something about this in the manual. > > No. > >>>> The reasoning: >>>> >>>> - wrapfig and longtable have been in there for a long time, we want to >>>> avoid breaking existing files whenever possible >>> >>> Assuming a mechanism exists that can detect when tabu is to be loaded >>> why only apply it there and not to the other optional packages? >> >> Because any automatic mechanism may cause problems with load sequence, >> so packages that are problematic in this way should require user attention. >> Hmm, have I just argued agains longtbl by saying this? > > If we are (i) aware of no known problems with a package and (ii) we > assume that loading package X–Z have little impact on compilation time > is it then not more rational to just add them as a default package? > > While automatic package handling is very exciting it could go awry. > > On conflicts. > > For me clashes mainly happen between macros defined multiple times, > e.g. compare \usepackage{amsmath, wasysym} and \usepackage{wasysym, > amsmath}. > > Exotic math packages, cross-reference packages, algorithm packages > seem to be potential sources, but none should conflict with amsmath. > There may be conlficts with hyperref, if anything. > > Packages that are known to cause trouble are usually known. Beside > stackoverflow here's an interesting list > > http://www.macfreek.nl/memory/LaTeX_package_conflicts > > Fixes are usually available. For instance, I use a filter to disable > fontenc/inputenc if pdflatex is not used (it breaks xelatex for me). > > –Rasmus > > -- > This is the kind of tedious nonsense up with which I will not put
