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>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <53B53F8B.7050802@nag.co.uk>
Date:         Thu, 3 Jul 2014 12:33:31 +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: David Carlisle <davidc@NAG.CO.UK>
Subject: Re: missing l3box counterparts of graphics' \resizebox variants
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53B51160.6070406@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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