<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <span dir="ltr"><<a href="mailto:erack@redhat.com" target="_blank">erack@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rick,<br>
<br>
On Friday, 2016-01-08 19:52:49 -0500, Rick C. Hodgin wrote:<br>
<br>
> The category is called *"Metric."*<br>
<span class="">><br>
> When conveying fractional values, such that 1.2345E-08 (which is<br>
> 0.000,000,012,345), it would do so in a metric-relative way using the<br>
> standard milli (10^-3), micro (10^-6), nano (10^-9), pico (10^-12), and so<br>
> on...<br>
><br>
</span>> In the example, the *Metric* display would cause the value to show up<br>
> as "*12,345<br>
> pu*" (pico-units) if the thousands separator was used.<br>
<br>
Could you give some examples what you think how the format code actually<br>
should look like?<br></blockquote><div>Eike, I never heard back from you after my reply.<br><br></div><div>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]").<br><br></div><div>In this way the base is always there:  "Metric"<br></div><div>Based on options, additional values are tagged on with colons:<br></div><div>:unitName<br></div><div>:bias=[tera,giga,mega,kilo,milli,micro,nano,pico]<br></div><div>:affix=[tera,giga,mega,kilo,milli,micro,nano,pico]<br></div><div><br></div><div>Is this acceptable?  Am I ready to begin coding? :-)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">
> There would be an<br>
> option to override the default "u" character in use, changing it into<br>
> something that may have significance for the cell, such as "s" or "seconds"<br>
> for seconds, "m" or "meters" for meters, and so on.<br>
<br>
</span>So, the unit itself would be a cell property, which replaces the generic "u"?<br>
<br>
That sounds related to the feature branch Markus already mentioned.<br>
<br>
> An ability to lock in a working range would also exist, such as *"show<br>
> everything in nano-units"* so that everything is adjusted to that base.  In<br>
> such a case, the above example above would present as "*12.345 nu*" instead<br>
> of in its default *pu*.<br>
<br>
Where/how should that "lock-in" happen? By applying a different number<br>
format to that range?<br>
<br>
<br>
One main problem with inventing new format code features is, that they<br>
don't survive an Excel roundtrip unless Excel has the same feature.<br>
I guess it doesn't.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Eike<br>
<br>
--<br>
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.<br>
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A<br>
Better use 64-bit 0x6A6CD5B765632D3A here is why: <a href="https://evil32.com/" rel="noreferrer" target="_blank">https://evil32.com/</a><br>
Care about Free Software, support the FSFE <a href="https://fsfe.org/support/?erack" rel="noreferrer" target="_blank">https://fsfe.org/support/?erack</a><br>
</font></span></blockquote></div><br></div></div>