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>
            <536BCCC6.7050902@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6yRLaW6nfTYVmgsLer5DomPpxTv-_nRwe1H6r46PZsJjA@mail.gmail.com>
Date:         Tue, 27 May 2014 11:58:30 -0400
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: \__dim_strip_bp:n
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <536BCCC6.7050902@googlemail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Thanks Heiko for the more accurate 800/803.  My mistake I believe.

On 5/8/14, Heiko Oberdiek <heiko.oberdiek@googlemail.com> wrote:
> On 07.05.2014 09:34, Joseph Wright wrote:
>>
>> 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.

I tend to agree with you that we should not let \__dim_strip_pt:n and
\__dim_strip_bp:n accept arbitrary junk.  That's easy to change, as
they are only used internally.  On the other hand, the public
\dim_to_pt:n and \dim_to_unit:n are documented as allowing multiple
units, for the use-case Joseph describes.

Perhaps a way out would be to make \dim_to_pt:n and \dim_to_unit:nn
check their units, and provide some \dim_cleanup:n function which hits
its argument with a dimexpr then removes everything after the pt.

    \cs_new:Npn \dim_cleanup:n #1
      {
        \exp_after:wN \@@_cleanup:w
        \dim_use:N \__dim_eval:w #1 \__dim_eval_end: \q_stop
      }
    \group_begin:
      \char_set_catcode_other:N \P
      \char_set_catcode_other:N \T
      \tl_to_lowercase:n
        {
          \cs_new:Npn \@@_cleanup:w #1 PT #2 \q_stop { #1 PT }
        }
    \group_end:

Regards,
Bruno