Suggestion
Rick C. Hodgin
rick.c.hodgin at gmail.com
Thu Jan 28 12:46:13 PST 2016
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 at googlemail.com> wrote:
> Hey Rick,
>
> On Thu, Jan 28, 2016 at 7:28 PM, Rick C. Hodgin <rick.c.hodgin at 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 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Jan 26, 2016 at 5:50 AM, Eike Rathke <erack at 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 at gmail.com>
>>>> > > On Tue, Jan 12, 2016 at 8:00 AM, Eike Rathke <erack at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20160128/18cf30ee/attachment.html>
More information about the LibreOffice
mailing list