<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin <span dir="ltr"><<a href="mailto:rick.c.hodgin@gmail.com" target="_blank">rick.c.hodgin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>><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></span><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></div></div></div></div></blockquote><div><br></div><div>Please forgive my dyslexia. It should be: Metric[:seconds][:bias=kilo][:affix=milli]<br><br></div><div>Each of the [] portions are optional, and would actually appear in a form like this:<br><br></div><div>Metric:seconds:bias=kilo:affix=milli<br><br></div><div>This would mean units will be: teraseconds, gigaseconds, megaseconds, kiloseconds, seconds, milliseconds, microseconds, nanoseconds, picoseconds<br></div><div>And the units in each cell are already sitting in kilosecond values.<br></div><div>And we are to base everything in milliseconds, meaning a value of 1.0 in the cell, is biased to be actually 1 kilosecond, which is 1,000 seconds, which is then translated to milliseconds, to reveal the display value of one million milliseconds, as in:<br><br></div><div>1 kilosecond = 1,000 seconds = 1,000,000 milliseconds<br><br></div><div>Make sense/<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span> > 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><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></span></div><br></div></div> </blockquote></div><br></div></div>