Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 21:52:17 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7MJqHaa007820 for ; Sat, 22 Aug 2009 21:52:17 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n7MJlbhk017766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Aug 2009 21:47:38 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7MCXL1g029540; Sat, 22 Aug 2009 21:47:31 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 288306 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 22 Aug 2009 21:47:30 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7MJlUIx023463 for ; Sat, 22 Aug 2009 21:47:30 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n7MJlP02017596 for ; Sat, 22 Aug 2009 21:47:30 +0200 Received: from morse.mittelbach-online.de (p54A83E1C.dip.t-dialin.net [84.168.62.28]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MKt72-1MewYf2e3a-000DDG; Sat, 22 Aug 2009 21:47:25 +0200 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 8E5E76EF0B; Sat, 22 Aug 2009 21:47:22 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <874332F9-007B-4945-87D5-48B28BBC11CC@gmail.com> <4A8E304C.4050208@morningstar2.co.uk> <4A8E4FF9.1080100@morningstar2.co.uk> <4B00C642-FF95-4CF7-9445-2C1C1CCF0904@gmail.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1/GzqVMqzD8HBp4SttYZ3N0/tSlTarHFE3AXfG 5jlxv25QSQ3O2NOLhQyPAsWRpugeZgKsWgKtDhQDZ4gjruPFxY Pa2IVA2eZB/0HTSpLl5Zg== X-Spam-Whitelist-Provider: Message-ID: <19088.19274.537302.830252@morse.mittelbach-online.de> Date: Sat, 22 Aug 2009 21:47:22 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: restricted templates (was: template customising) To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4B00C642-FF95-4CF7-9445-2C1C1CCF0904@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -106.599 () BAYES_00,RCVD_IN_DNSWL_MED,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 22 Aug 2009 19:52:17.0779 (UTC) FILETIME=[0DBDCC30:01CA2362] Status: R X-Status: X-Keywords: X-UID: 5981 Will Robertson writes: > > I imagine that we will end up providing one or more very general > > templates with some restricted ones to solve at least parts of the > > issue. > > [...] > > Since templates don't cascade (i.e., changes to higher templates don't > flow on to templates and instances down the line) the idea of a > restricted template seems more limited to cases when you literally > need to restrict setting certain parameters in order to keep the > template (or, rather, the design that the template produces) working. they cascade as long as you don't freeze a design by instanciating it, ie if you do the template restriction prior to do \DeclareInstance then changes will appear. However, the use case for the "restricted templates" was something quite different, so I'm not surprised that it doesn't quite fit the bill here. The idea behind them is the following: with certain publishers you do find something like "house style" where certain parts of the document layout is predefined, while other design elements are flexible and allow variation depending on the target document class. For example, the publisher might want to always use certain fonts, etc. Now rather than asking them to take basic templates, copy them and changing their implementation to take out some of the basic customization possibilities, the idea was to offer a mechanism through which come aspects of templates could be frozen. The house style, would then provide a set of restricted template and document classes written in the house style would produce their design by restricting themselves to use only templates from the house style. The way things are written the unrestricted templates would still be available for those people who want to use them, so this is more a guiding principle and not a real prevention mechanism. The other use case is to set some common values for instances by taking a template restricting it in the design and then reuse the restricted template several times for instantiation, e.g., \DeclareRestrictedTemplate{sectioning}{xxx}{vertical-heading} { font = \fontfamily{ptm}\fontseries{b}\selectfont ....} \DeclareInstance{sectioning}{chapter}{xxx}{...} % no need to set font \DeclareInstance{sectioning}{section}{xxx}{...} % any more \DeclareInstance{sectioning}{subsection}{xxx}{...} Both use cases are really for the design layer and aren't really applicable for user overwrites on individual documents. Whether or not that is really a good idea or only snytactic sugar not worth having, I'm not so sure these days, but that was the original motivation. frank