References: <C375E494-10D0-47E9-8B30-97FED78F51F2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: normal
Sensitivity: Normal
Message-ID:  <452678254.130451.1288264112388.JavaMail.fmail@mwmweb011>
Date:         Thu, 28 Oct 2010 13:08:32 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Uwe Lueck <uwe.lueck@WEB.DE>
Subject: Re: New "interfaces" package
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <C375E494-10D0-47E9-8B30-97FED78F51F2@gmail.com>
Precedence: list
Status: R

"Will Robertson" <wspr81@GMAIL.COM>, 28.10.2010 07:42:16:
>There's an interesting new package on CTAN called "interfaces" (http://ctan.org/pkg/interfaces) that does the sort of thing I've been thinking for a long time now would be useful (or at least interesting) for LaTeX.
>
>What it does is take a large selection of non-related packages and apply a consistent interface on top of them all. E.g., enumitem, titlesec, fancyhdr, and so on, are all given wrappers with keyval options for their use.
>
>I think it's an interesting idea to "endorse" a particular set of well-used packages, although long term I'd prefer for the packages themselves to offer such an interface natively. This is also an interesting project because it maps out the scope of what requirements might be necessary for a possible future LaTeX3 "document specification". (Also see ConTeXt MkIV which would make for a good comparison here.)

An aspect I like is that the user could call formatting options without knowing which package (s)he must load for this. (Maybe this has been said already without being clear to me -- never used koma.)

I thought of this for a project with a "visual" style choice interface. Formatting options could be described by their effect (rather than name) -- clickable. The interface constructs the document preamble from those clicks. 

Somewhat contrary to Will: the "endorsed" packages needn't be loaded unless the user chooses an option that needs a certain package. This way such an interface would "support" or "cover" certain packages, rather than "endorsing" some.

This also reminds me of memoir.cls, "endorsing" (copying) certain "standard" packages; yet I have never studied by which commands the features of those packages are accessed by the user.

... Uwe.