User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
MIME-Version: 1.0
References: <5366C875.9040709@googlemail.com>                                 
            <5367453E.3030906@morningstar2.co.uk> <5369962B.2020905@gmail.com> 
            <5369D54F.10503@googlemail.com>
            <5369E218.4090809@morningstar2.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Message-ID:  <536BCCC6.7050902@googlemail.com>
Date:         Thu, 8 May 2014 20:28:22 +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: Heiko Oberdiek <heiko.oberdiek@GOOGLEMAIL.COM>
Subject: Re: \__dim_strip_bp:n
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <5369E218.4090809@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 07.05.2014 09:34, Joseph Wright wrote:
> On 07/05/2014 07:40, Heiko Oberdiek wrote:
>> On 07.05.2014 04:10, Qing Lee wrote:
>>> On 2014-05-05 at 16:01:02 +0800 GMT, Joseph Wright wrote:
>>>> On 05/05/2014 00:08, Heiko Oberdiek wrote:
>>
>>>>>    \cs_new:Npn \__dim_strip_bp:n #1
>>>>>      { \__dim_strip_pt:n { 0.996 26 \__dim_eval:w #1 \__dim_eval_end:
>>>>> } }
>>
>>>>>      \dimexpr 0.99626\dimexpr #1\relax\relax
>>
>>>>> Improved version with higher precision:
>>>>>
>>>>>    \cs_new:Npn \__dim_strip_bp:n #1
>>>>>      {
>>>>>        \__dim_strip_pt:n
>>>>>          {
>>>>>            \__dim_eval:w ( #1 ) * 800 / 803 \__dim_eval_end:
>>>>>          }
>>>>>      }
>>
>>> The new definition will be broken if its argument contains additional
>>> units. E.g.,
>>>
>>>     \__dim_strip_bp:n { 1 bp pt }

Thanks Quing Lee for noticing that there is a "feature" that I have
overlooked:

> Before making any further changes (and adding tests for the defined
> behaviour), I think it's worth briefly considering why \__dim_strip_pt:n
> and \__dim_strip_bp:n are (currently) documented as accepting multiple
> units in the argument. (I was drafting this message before Heiko's reply!)
> 
> While it's not in the sources, from memory the idea was that allowing
> input such as
> 
>   \__dim_strip_bp:n { 1 bp pt }
> 
> means that at a 'higher level' something like
> 
>   \cs_new:npn \foo #1
>     { \_dim_strip_bp:n { #1 pt } }
> 
> will work with
> 
>   \foo { 1 bp }
> 
> and
> 
>   \foo { 1 } % Assumes pt
> 
> will work. The idea was, I think, allowing an approach something like
> \@defaultunits in the LaTeX2e kernel or \Gin@defaultbp in graphics but
> in an expandable form.
> 
> Now, that may not be a good plan: the functions here are supposed to be
> relatively low-level (they are for writing driver code), and it is
> likely to be better to require 'properly defined' units on the input.

IMHO, the feature "default unit" belongs to the "toolbox level" for
defining user interfaces.

> As I say, before I make any further change here it would be useful to
> have a proper idea of what is actually required.

Either way,
  \dimexpr 0.99626\dimexpr
belongs to the past and can/should be replaced by a "scaling" operation
of \dimexpr.

Best regards.
  Heiko Oberdiek