[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [export] Should sidewaystable option automatically add rotating

From: Andreas Leha
Subject: Re: [O] [export] Should sidewaystable option automatically add rotating package?
Date: Mon, 16 Sep 2013 22:21:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Rasmus <address@hidden> writes:

> Hi Carsten,
> Carsten Dominik <address@hidden> 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:

- 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]