Suggestion

[Rick C. Hodgin]

On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <erack at 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?
>

If you're referring to the internal format codes, then "Metric" by default
(like "General"), and to override the name something like "Metric:seconds"
as an override of the default "u" to use "seconds".


>
> > 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"?
>

Yes.  And by default, it would simply be a "u", but then the user could set
it to be anything they want.


>
> That sounds related to the feature branch Markus already mentioned.
>

The important part of the Metric feature is that it always wraps the value
to the nearest power of 3, and shows values in those powers.  0.1234 would
be shown as 123.4 milliunits, or 1,234 microunits, for example (however the
user has set it up), and not as "0.1234 u" (unless they are explicitly
stating to use "Units", which would be something they'd have to do
manually).


>
> > 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?
>

It would force it to be in a particular power of 3 range.  The example
above of 0.1234 could be locked into nanounits (10^(-9)), which would then
show as 123,400,000 nu, rather than its default form of  123.4 mu, etc.


> 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.
>

Agreed.  It doesn't exist in Excel to my knowledge.


>
>   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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20160112/dabf33e1/attachment.html>