Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Markus,

I had asked for alternate syntax suggestions on what formatting codes
should be used and received silence.

I have no real desire to create an entire unit feature branch for this
feature, but only to make this one change.  I am content to write the
changes as I have outlined them, and then post the patches publicly for
those who wish to integrate them.

It's no biggie.  I offered my suggestion.  It's out there now.  I'll
incorporate it into the code and post the patch.  If someone else wants to
use it for the official introduction into LibreOffice, that's fine.  If
not, that's fine too.  It's been offered...

Best regards,
Rick C. Hodgin


On Thu, Jan 28, 2016 at 3:38 PM, Markus Mohrhard <
markus.mohrhard@googlemail.com> wrote:

Hey Rick,

On Thu, Jan 28, 2016 at 7:28 PM, Rick C. Hodgin <rick.c.hodgin@gmail.com>
wrote:

Since I haven't heard back, I'll go ahead and develop this using the
syntax I propose.  It's easily changed later.

Also two more additions:
(1)  Adding a separator symbol for decimals, as in 1234.4321 being
"1,234.432,1"
(2)  Adding a feature to Writer which allows an export of every word
using a page-based (page,X,Y) coordinate syntax for importing into other
tools.  It would be a type of XML layout, something like this:

<coordinates document="filename...">
  <page p="1">
    <word x="3.212" y="2.187" text="Hi"/>
    <line x1=".." y1=".." x2=".." y2=".." thickness=".."/>
  </page>
</coordinates>

And so on, and I would probably abbreviate things to <w> and <l> for word
and line, and t=".." for text, etc...

I had a need for this yesterday, but I couldn't find an easy format which
would allow me to replicate literal page,X,Y coordinates without extended
parsing.  A simple file layout like that would allow export, and
potentially import.

Best regards,
Rick C. Hodgin




So as Eike and I already mentioned this is actually part of what should be
developed as part of the unit feature branch with a different syntax. Your
proposed syntax does not fit into the existing number format code and does
conflict a lot with the ideas behind the unit feature. Please try to read
some of the existing code before working on something that has in its
current form only a limited chance of being merged upstream.

If you want to talk about how to fit your ideas into the general calc
concepts please come to IRC during EU working hours.

Regards,
Markus





On Tue, Jan 26, 2016 at 8:22 AM, Rick C. Hodgin <rick.c.hodgin@gmail.com>
wrote:



On Tue, Jan 26, 2016 at 5:50 AM, Eike Rathke <erack@redhat.com> wrote:

Hi Rick,

On Monday, 2016-01-25 16:26:53 -0500, Rick C. Hodgin wrote:

On Mon, Jan 25, 2016 at 3:21 PM, Rick C. Hodgin <
rick.c.hodgin@gmail.com>
On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <erack@redhat.com>
wrote:
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]").


Please forgive my dyslexia.  It should be:
Metric[:seconds][:bias=kilo][:affix=milli]

Each of the [] portions are optional, and would actually appear in a
form
like this:

Metric:seconds:bias=kilo:affix=milli

I don't see how that would fit into the existing number format code
syntax. It looks like something completely different.


When I look to the existing formats, they seem to be a string parsed
from left-to-right indicating what is conveyed in those places.  So, I
don't see where this one would be "something completely different" or
anything that's unusable.

It would be applied using this type of logic (given in easily
human-readable form):

if (string.lowercase().beginsWith("metric")) {
    // "Metric" parsing
} else {
    // Use the existing code for other format parsing
}

I'm open to suggestions.  What do you propose?

The reason I used colons was to keep the formatting options
concatenated, though it could use another character, or different words or
symbols for words, as in:  Metric:seconds:B-K:A-M

And if they used the default "units" then it would simply be:
Metric:B-K:A-M

-----
Number:  General, "General"
Number:  -1234, "0"
Number:  -1234.12, "0.00"
Number:  -1,234, "#,##0"
Number:  -1,234.12, "#,##0.00"
Number:  -1,234.12, "#,###.00"
Number:  (1,234), "#,##0_);(#,##0)"
Number:  (1,234.12), "#,##0.00_);(#,##0.00)"

Percent:  -13%, "0%"
Percent:  -12.95%, "0.00%"

Currency:  -$1,234 (black), "[$$-409]#,##0;-[$$-409]#,##0"
Currency:  -$1,234.00 (black), "[$$-409]#,##0.00;-[$$-409]#,##0.00"
Currency:  -$1,234 (red), "[$$-409]#,##0;[RED]-[$$-409]#,##0"
Currency:  -$1,234.00 (red), "[$$-409]#,##0.00;[RED]-[$$-409]#,##0.00"
Currency:  -$1,234.-- (red), "[$$-409]#,##0.--;[RED]-[$$-409]#,##0.--"
Currency:  -1,234.00 USD (black), "#,##0.00 [$USD];-#,##0.00 [$USD]"
Currency:  -1,234.00 USD (red), "#,##0.00 [$USD];[RED]-#,##0.00 [$USD]"
Currency:  -$1,234 (black), "[$$-409]* #,##0;-[$$-409]* #,##0"
Currency:  -$1,234.00 (black), "[$$-409]* #,##0.00;-[$$-409]* #,##0.00"

Date:  12/31/99, "M/D/YY"
Date:  Friday, December 31, 1999, "NNNNMMMM DD, YYYY"
Date:  12/31/99, "MM/DD/YY"
Date:  12/31/1999, "MM/DD/YYYY"
Date:  Dec 31, 99, "MMM D, YY"
Date:  Dec 31, 1999, "MMM D, YYYY"
Date:  31. Dec. 1999, "D. MMM. YYYY"
Date:  December 31, 1999, "MMMM D, YYYY"
Date:  31. December 1999, "D. MMMM YYYY"
Date:  Fri, Dec 31, 99, "NN, MMM D, YY"
Date:  Fri 31/Dec 99, "NN DD/MMM YY"
Date:  Fri, December 31, 1999, "NN, MMMM D, YYYY"
Date:  Friday, December 31, 1999, "NNNNMMMM D, YYYY"
Date:  12-31, "MM-DD"
Date:  99-12-31, "YY-MM-DD"
Date:  1999-12-31, "YYYY-MM-DD"
Date:  12/99, "MM/YY"
Date:  Dec 31, "MMM DD"
Date:  December, "MMMM"
Date:  4th quarter 99, "QQ YY"
Date:  1, "WW"
Date:  12/31/99 01:37 PM, "MM/DD/YY HH:MM AM/PM"
Date:  12/31/1999 13:37:46, "MM/DD/YYYY HH:MM:SS"
Date:  Friday, 22 Tevet 5760, "[~jewish]NNNND MMMM YYYY"
Date:  Friday, Tevet 22 5760, "[~jewish]NNNNMMMM D YYYY"
Date:  Fri Tevet 22 5760, "[~jewish]NN MMMM D YYYY"
Date:  Fri 22 Tevet 5760, "[~jewish]NN D MMMM YYYY"
Date:  22 Tevet 5760, "[~jewish]D MMMM YYYY"
Date:  Tevet 22 5760, "[~jewish]MMMM D YYYY"
Date:  22 Tevet, "[~jewish]D MMMM"
Date:  Tevet 22, "[~jewish]MMMM D"
Date:  Tevet 5760, "[~jewish]MMMM YYYY"
Date:  Tevet, "[~jewish]MMMM"

Time:  13:37, "HH:MM"
Time:  13:37:46, "HH:MM:SS"
Time:  01:37 PM, "HH:MM AM/PM"
Time:  01:37:46 PM, "HH:MM:SS AM/PM"
Time:  876613:37:46, "[HH]:MM:SS"
Time:  37:46.00, "MM:SS.00"
Time:  876613:37:46.00, "[HH]:MM:SS.00"
Time:  12/31/99 01:37 PM, "MM/DD/YY HH:MM AM/PM"
Time:  12/31/1999 13:37:46, "MM/DD/YYYY HH:MM:SS"

Scientific:  -1.23E+003, "0.00E+000"
Scientific:  -1.23E+03, "0.00E+00"

Fraction:  -1234 1/8, "# ?/?"
Fraction:  -1234 10/81, "# ??/??"

Boolean Value:  TRUE, "BOOLEAN"

Text:  @, "@"


  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




_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice




Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.