Suggestion
Markus Mohrhard
markus.mohrhard at googlemail.com
Thu Jan 28 12:38:55 PST 2016
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/dc5d016c/attachment.html>
More information about the LibreOffice
mailing list