[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: Carsten Dominik
Subject: Re: [O] [export] Should sidewaystable option automatically add rotating package?
Date: Tue, 17 Sep 2013 06:48:27 +0200

On 17.9.2013, at 03:45, Eric Abrahamsen <address@hidden> wrote:

> On 09/17/13 03:26 AM, Rasmus wrote:
>> 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).
> 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.

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

Thanks for your input, Eric.

- Carsten

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

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