User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.6.0
MIME-Version: 1.0
References: <20140627125102.GA10460@hzdr.de>                                 
            <5978C2CE-C53F-4DA4-9262-D9C151E0B962@gmail.com>                   
            <20140628130457.GA17997@hzdr.de>                                 
            <53B50587.8060700@morningstar2.co.uk>                      
            <20140703074723.GA23501@hzdr.de>           
            <53B51160.6070406@morningstar2.co.uk> <53B53F8B.7050802@nag.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Message-ID:  <53B550E0.3090002@morningstar2.co.uk>
Date:         Thu, 3 Jul 2014 13:47:28 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: missing l3box counterparts of graphics' \resizebox variants
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53B53F8B.7050802@nag.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 03/07/2014 12:33, David Carlisle wrote:
> On 03/07/2014 09:16, Joseph Wright wrote:
>>   3. Are these more complex possibilities needed for \coffins_...?
>>      (Currently there is only \coffin_resize:Nnn.)
> 
> I suspect not, a classic box just has three associated lengths so that
> pretty much determines
> the "packaged" resize combinations.
> 
> But for a coffin the equivalent of height/depth is really the y
> coordinates of any handle
> relative to the total height; and width similarly can be split by the x
> coordinate of any handle
> thus I think there are too many possibilities to wrap these in simple
> named commands and the caller
> will need to calculate the scale factors required.
> 
> David

Good points and a handily defensible position :-)
-- 
Joseph Wright