Re: [export] Should sidewaystable option automatically add rotating package?

[Carsten Dominik <carsten.dominik@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4170 bytes --]


On 17.9.2013, at 03:45, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

> 
> On 09/17/13 03:26 AM, Rasmus wrote:
>> Hi Carsten,
>> 
>> Carsten Dominik <carsten.dominik@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).
> 
> I'm not an expert, but I haven't read about or experienced any
> particular clashes, so I've made this my standard table package. I'd
> feel a little weird about enforcing that on most users, though...
> 
>>>>> - 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.
> 
> [...]
> 
> I'm not too in favor of automatic package detection. Unless it works
> nearly perfectly, it just seems like trading one kind of user irritation
> for another.
> 
> Personally, I _always_ blast the default packages and load my own stuff.
> 
> One potential middle ground would be providing defaults "sets": for
> instance LATEX_MATH_DEFAULTS (or whatever), that provided a couple
> choices for math-related package suites that are known to work well
> together.
> 
> Meh, maybe not.
> 
>> Fixes are usually available.  For instance, I use a filter to disable
>> fontenc/inputenc if pdflatex is not used (it breaks xelatex for me).
> 
> If anything was going to be automatically detected and handled, it seems
> like it should be this. This is one of the main reasons I gave up trying
> to use the defaults at all.

Rasmus, 
I'd be interested to see a patch to this effect.

Thanks for your input, Eric.

- Carsten

> 
> Not too helpful, I know...
> 
> E


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]