Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p0D8iJQc030404 for ; Thu, 13 Jan 2011 09:44:21 +0100 Received: (qmail 19728 invoked by alias); 13 Jan 2011 08:44:14 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 13 Jan 2011 08:44:12 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx017) with SMTP; 13 Jan 2011 09:44:12 +0100 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 p0D8fM95023113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2011 09:41:22 +0100 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 p0D8MvwW025347; Thu, 13 Jan 2011 09:41:11 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 775973 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 13 Jan 2011 09:41:11 +0100 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 p0D8fBcO012841 for ; Thu, 13 Jan 2011 09:41:11 +0100 Received: from ueamailgate01.uea.ac.uk (ueamailgate01.uea.ac.uk [139.222.131.184]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p0D8ehW1022013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jan 2011 09:40:47 +0100 Received: from ueams02.uea.ac.uk (ueams02.uea.ac.uk [139.222.131.131]) by ueamailgate01.uea.ac.uk (8.13.8/8.13.8) with ESMTP id p0D8egg5002922 for ; Thu, 13 Jan 2011 08:40:42 GMT Received: from [139.222.113.126] by ueams02.uea.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1PdIjY-000816-G9; Thu, 13 Jan 2011 08:40:40 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 References: <19748.48031.990921.327320@morse.mittelbach-online.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, outgoing) X-CanIt-Geo: ip=139.222.131.131; country=GB; region=I9; city=Norwich; latitude=52.6333; longitude=1.3000; http://maps.google.com/maps?q=52.6333,1.3000&z=6 X-CanItPRO-Stream: UEA:outgoing (inherits from UEA:default,base:default) X-Canit-Stats-ID: 67075859 - 1646e197aff2 - 20110113 X-Scanned-By: CanIt (www . roaringpenguin . com) on 139.222.131.184 Message-ID: <4D2EBA8B.5010504@morningstar2.co.uk> Date: Thu, 13 Jan 2011 08:40:43 +0000 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: xcoffins: missing functions? To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <19748.48031.990921.327320@morse.mittelbach-online.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDtMgfETrECMLUO9erHzOJe7j3G660N4yBY6XHH YPYtmQj6mbYUTZ3LnaFANLWrKE7/wIDhnv+VrW0hxOapLRUwuY9oBqo5h+Dh9B42XlFTMTKlXDju GaV8Q==V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6564 On 05/01/2011 18:42, Frank Mittelbach wrote: > What I have in mind are primarily rules, specified not by giving absolute > length but rather specifying the end points in relation to the coffin handles. > A more or less natural extension of this would be something like "leaders" the > way TeX defines them, or a variation of that. But perhaps that is already too > much and rules are enough. > > I don't think that it is right to try to turn the concept of coffins into some > sort of general purpose graphics language, ie. really complicated things are > probably better done differently but it would be nice if the more common > layouts could be easily decribed in this way and right now at least the rules > seems to me something that is clearly necessary. > > But is there anything else you feel would be essential? And if so what? > > Also, what kind of paramerization would be suitable for such objects (again > thinking about what is commonly needed and not so much what would be > theoretically possible in some arcane setup)? I'd been thinking about this, and it lead me back to some comments on the more general point about optional arguments. Currently, we're using positional optional arguments for the coffin functions, for example \JoinCoffins * \ [ , ] \ [ , ] ( , ) A good case can be made for reducing the use of arguments in this way and moving to key-value syntax. I quite like the requirement for the mandatory items to be separate arguments, but can see that something like: \JoinCoffins * [ coffin1-pole1 = , coffin1-pole1 = , coffin2-pole2 = , coffin2-pole2 = , x-offset = , y-offset = , ] \ \ might be a better long-term approach. I've assumed that we'd keep the optional stuff as optional overall but in one argument, and that the '*' still makes sense here (an alternative would be 'expand-bounding-box' or similar as a Boolean). I'm also assuming that two arguments for each handle is better than coffin1-handle = { , } , as at this stage I want to highlight the general point. (I'm not overly keen on requiring braces in the key-value list if there is an alternative which is also clear.) The reason this is relevant to rules is that there are a number of parameters that come to mind. A rule needs to be placed relative to a coffin, which as with other alignments may need a handle on the coffin and an offset. At the rule end, we may need the colour of the rule and a handle on the rule for the alignment. We also need dimensions for the rule, but these might want to be relative or absolute. The bounding box for the coffin may need to expand or may be conserved. Out of this list, the only absolute requirement is the coffin name. So a key-value list would seem much more reasonable than optional arguments \AddRuleToCoffin * [ absolute-width = , absolute-height = , coffin-pole1 = , coffin-pole2 = , color = , color-model = , relative-width = , relative-height = , rule-pole1 = , rule-pole2 = , x-offset = , y-offset = , ] \ Obviously, there may need to be some adjustment to the keys. For example, my model above assumes that absolute and relative dimensions are given separately, whereas you could have just 'height' and 'width' with a 'absolute-dimensions' Boolean (I think this might be less clear). The same arguments about '*' and poles versus handles apply here as with \JoinCoffins, etc. The general point for me is that if you want this flexibility for rules then I think you need a similar interface for the rest of the coffins module. I also note that it would be possible to extend this approach to leaders by making rules a special case of a more general \AddLeadersToCoffin function. (Function names may of course need some work too!) -- Joseph Wright