Re: Suggestion

On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <erack@redhat.com> wrote:

> Hi Rick,
>
> On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:
>
> > The category is called *"Metric."*
> >
> > When conveying fractional values, such that 1.2345E-08 (which is
> > 0.000,000,012,345), it would do so in a metric-relative way using the
> > standard milli (10^-3), micro (10^-6), nano (10^-9), pico (10^-12), and
> so
> > on...
> >
> > In the example, the *Metric* display would cause the value to show up
> > as "*12,345
> > pu*" (pico-units) if the thousands separator was used.
>
> Could you give some examples what you think how the format code actually
> should look like?
Eike, I never heard back from you after my reply.

The format would be "Metric" with "Metric:seconds" given for a specific
override for the units name.  And there are a few other options that I
would like to append including a bias that the data may already be in, such
as kilo-units ("Metric[:seconds][:bias=kilo]") and an override base to use,
such as always displaying in milli-units
("Metric[:seconds][:bias=kilo][affix:milli]").

In this way the base is always there:  "Metric"
Based on options, additional values are tagged on with colons:
:unitName
:bias=[tera,giga,mega,kilo,milli,micro,nano,pico]
:affix=[tera,giga,mega,kilo,milli,micro,nano,pico]

Is this acceptable?  Am I ready to begin coding? :-)


> > There would be an
> > option to override the default "u" character in use, changing it into
> > something that may have significance for the cell, such as "s" or
> "seconds"
> > for seconds, "m" or "meters" for meters, and so on.
>
> So, the unit itself would be a cell property, which replaces the generic
> "u"?
>
> That sounds related to the feature branch Markus already mentioned.
>
> > An ability to lock in a working range would also exist, such as *"show
> > everything in nano-units"* so that everything is adjusted to that base.
> In
> > such a case, the above example above would present as "*12.345 nu*"
> instead
> > of in its default *pu*.
>
> Where/how should that "lock-in" happen? By applying a different number
> format to that range?
>
>
> One main problem with inventing new format code features is, that they
> don't survive an Excel roundtrip unless Excel has the same feature.
> I guess it doesn't.
>
>   Eike
>
> --
> LibreOffice Calc developer. Number formatter stricken i18n
> transpositionizer.
> GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563
> 2D3A
> Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
> Care about Free Software, support the FSFE https://fsfe.org/support/?erack