Skip to content

LibreOffice 4.3 new Calc feature: user selectable text conversion models

In LibreOffice 4.3 the user will be able to select how textual cell content shall be treated in arithmetic operations.

This setting determines how to treat text when encountered as operand in an arithmetic operation or as argument to a function that expects a number instead.

Selectable under Tools → Options → LibreOffice Calc → Formula in Detailed calculation settingsCustomDetails from Conversion from text to number are:

Generate #VALUE! error
=1+"1" or =1+"x" give #VALUE!
Treat as zero
=1+"1" or =1+"x" give 1
Convert only unambiguous
=1+"1" gives 2, but =1+"1.000" or =1+"x" give #VALUE!
Convert also locale dependent
=1+"1.000" may be 2 or 1001 ... =1+"x" gives #VALUE!

For Generate #VALUE! error and Treat as zero, setting the Treat empty string as zero option is disabled and the option is aligned to these settings, for Convert only unambiguous and Convert also locale dependent the Treat empty string as zero option can be set independently.

When reading documents created by other spreadsheet applications or older versions of LibreOffice, and to interchange documents between different locales, the Convert only unambiguous with Treat empty string as zero = True setting is recommended, though LibreOffice so far acted as Convert also locale dependent with Treat empty string as zero = False, which is the reason that option is kept as default.

The best setting to create new documents that can be interpreted by all spreadsheet applications without on-the-fly string conversion is Generate #VALUE! error. With this option enabled possible data errors can be spotted early. Not having to convert strings during calculation is also faster, of course.

User selectable text conversion models in LibreOffice 4.3

 

Editable Date Acceptance Patterns in LibreOffice

The introduction of more restrictive date acceptance patterns in LibreOffice 3.6 (see earlier blog entries here and here) generated quite some discussion whether the change was good or bad. The fact that not all locales had patterns for incomplete (only day and month) date input added to their data also added some angry voices.

Independent from that there was one thing overlooked: users want to be able to input dates using the numeric keypad and in locales with a '.' dot date separator that was not possible anymore because usually then there is no dot on the keypad due to the decimal separator being different. That certainly needed to be addressed.

There is no way to satisfy everyone with a default set of patterns, I therefore implemented a Date acceptance patterns edit field in the Tools→Options→LanguageSettings→Languages dialogue that follows the selected locale and enables users to add, edit and remove patterns.

Date acceptance patterns edit field.
Date acceptance patterns edit field.

The change is currently in master and pending review as a late feature for inclusion to the 3.6.2 release.

Example for the German de-DE locale:

  • default patterns: D.M.Y;D.M.
  • to enable additional input on numeric keypad: D.M.Y;D.M.;D-M-Y;D-M
    • if 3-4 shall not result in a date, D-M- could be used instead of D-M
    • note that to enter an ISO 8601 Y-M-D date with a D-M-Y pattern active one needs to enter a year >31 or with at least 3 digits, e.g. 011
  • instead of D-M-Y;D-M also D/M/Y;D/M could be used

Changes to the patterns become effective immediately after having confirmed and closed the dialog.

Does your LibreOffice locale need a date acceptance pattern for incomplete date input?

Update 2012-08-31T23:08+0200 : Editable Date Acceptance Patterns in LibreOffice

As explained in an earlier article a new feature will be available with LibreOffice 3.6 that limits date recognition of input to predefined locale dependent patterns to prevent erroneous detection of dates. To be able to input incomplete dates a locale needs date acceptance patterns defined in its locale data, quite a lot submissions of such patterns have already been included, but many locales do not have any pattern assigned yet. For these locales date input will only be possible as a complete date, no incomplete dates will be accepted. Maybe your locale should be enabled for incomplete date input but isn't yet? Then please submit the pattern(s), either as a comment to this blog post, or on the LibreOffice l10n mailing list if you are involved with LibO localization anyway, or simply mail me.

Locales without explicit DateAcceptancePattern elements:
(one implicit full date pattern is always generated)

ak_GH    ar_DZ    ar_EG    ar_OM    ast_ES    az_AZ    bn_IN    bs_BA    cv_RU    da_DK    de_AT    de_CH    de_LI    de_LU    dsb_DE    dz_BT    ee_GH    el_GR    en_AU    en_CA    en_GB    en_GH    en_JM    en_NA    en_ZA    eo    es_AR    es_BO    es_CL    es_CO    es_CR    es_DO    es_EC    es_GT    es_PE    eu    fa_IR    fo_FO    fr_CA    fur_IT    fy_NL    gl_ES    gsc_FR    gug_PY    ha_GH    haw_US    he_IL    hi_IN    hil_PH    hr_HR    hsb_DE    ht_HT    hu_HU    hy_AM    ia    id_ID    it_CH    jbo    ka_GE    kk_KZ    kl_GL    km_KH    ko_KR    ku_TR    ky_KG    la_VA    lb_LU    lg_UG    lif_NP    ln_CD    lo_LA    ltg_LV    lv_LV    mai_IN    mk_MK    ml_IN    mn_MN    mt_MT    my_MM    myv_RU    ne_NP    no_NO    oc_FR    om_ET    or_IN    pjt_AU    pl_PL    plt_MG    ro_RO    rue_SK    rw_RW    sc_IT    sg_CF    shs_CA    so_SO    sr_RS    sv_FI    sv_SE    sw_TZ    tg_TJ    th_TH    ti_ER    tk_TM    tpi_PG    ug_CN    uk_UA    ur_PK    uz_UZ    vi_VN    wa_BE    zh_HK    zh_MO    zh_SG   

Locales with explicit DateAcceptancePattern elements:

  • an_ES:
    • D/M
  • be_BY:
    • D/M/
    • D.M.
  • bg_BG:
    • D.M.Y г.
    • D.M.Y г.
    • D.M.Y Г.
    • D.M.Y Г.
  • br_FR:
    • D/M
  • ca_ES:
    • D/M
  • cs_CZ:
    • D.M.
    • D. M.
    • D. M. Y
    • D. M.
    • D. M. Y
  • de_DE:
    • D.M.
  • en_US:
    • M/D
  • es_ES:
    • D/M
  • et_EE:
    • D.M
    • D. M
    • D.M.
    • D. M.
  • fi_FI:
    • D.M.
  • fr_BE:
    • D/M
  • fr_CH:
    • D/M
    • D.M.
  • fr_FR:
    • D/M
  • fr_LU:
    • D/M
  • gd_GB:
    • D/M
    • D-M
  • is_IS:
    • D/M/
    • D.M.
  • it_IT:
    • D/M
  • ja_JP:
    • M-D
    • M/D
    • M/D
    • Y.M.D
    • Y/M/D
    • Y年M月D日
    • M月D日
  • kab_DZ:
    • D/M
  • lt_LT:
    • M-D
  • nl_BE:
    • D/M
  • nl_NL:
    • D-M
  • pt_AO:
    • D-M
  • pt_BR:
    • D/M
  • pt_PT:
    • D-M
  • ru_RU:
    • D.M.
    • D/M/
  • sk_SK:
    • D.M.
    • D. M.
    • D. M. Y
    • D. M.
    • D. M. Y
  • sl_SI:
    • D. M. Y
    • D.M.
    • D. M.
  • tr_TR:
    • D.M
    • D/M
    • D-M
  • zh_CN:
    • M-D
    • M/D
    • M/D
    • Y.M.D
    • Y/M/D
    • Y年M月D日
    • M月D日
  • zh_TW:
    • Y.M.D
    • M-D
    • M/D
    • Y年M月D日
    • M月D日

If some of the entries seem to be duplicates within a locale and include spaces, that's because they are defined both with normal space and with breaking space to accommodate both input variants.

LibreOffice goes collaborating

One week of successful hacking at the Cambridge collaboration hackfest.

After I already struggled with Telepathy for some while, trying to implement DBus tubes over XMPP, Michael Meeks arranged a collaborative hackfest at Cambridge, where Collabora Ltd. is situated who to a large part are the maintainers of the Telepathy library. Nice to meet some of these guys (btw, if you happen to be in Cambridge and are into good Indian food go for the Golden Curry).

So last week Will Thompson from Collabora was set aside to work with us, who was of great help and immediately spotted why my tube acceptor never caught any offered tube, silly me, not spinning GMainLoop yet another time to wait for a specific state change ... Before, a connection to DBus could already be setup and a session between two contacts initiated and a tube offered, but I didn't get to the point where a tube was really established.

What we achieved from Tuesday to Thursday / Friday morning:

  • use Empathy's XMPP account and contact list
  • establish a DBus tube between an account and a contact
  • transfer a file over the tube (which shall be the document to be worked on)
  • intercept Calc input (basic proof of concept)
  • transfer input as packet through tube
  • receive on other end and use as input

Kudos again to Will, who made the fast progress on the Telepathy bits possible. And Michael for tearing apart Calc's ScDocFunc. That I now have to glue together again somehow ;-)

All happens on the LibreOffice feature/tubes2 branch. You're more than welcome to help out, especially if you're familiar with Telepathy or like to implement some dialogs in VCL such as an account/contact picker or have ideas how to improve our bits. You might also be interested that further work on this topic is offered as a Google Summer of Code (GSoC) project. There's plenty to do.

Btw, the next opportunity to collaboratively hack on collaboration would be at the Hamburg Hackfest on April 14/15 :-)

Update 2012-03-27T13:25+0200
Michael has some more details with bells and whistles and video over at his blog, video here:

Hacking Calc the other way

I've seen many (ab)uses of spreadsheets during my years as an OOo/LibO Calc developer, but this Spreadsheet as Music Tracker-Sequencer is the most hackish one.

You might also be interested in the How-To video.

[via Bjoern's My productivity suite sounds better than yours ...]

LibreOffice date acceptance patterns

Update 2012-08-31T23:08+0200 : Editable Date Acceptance Patterns in LibreOffice

Abstract: Calc's (and in Writer table) cell input now needs to match locale dependent date acceptance patterns before it is recognized as a valid date.

Previously the number formatter's input scanner was very lax in what it accepted as a "valid" date. All combinations of 2-3 numbers separated by '.' '/' '-' or the locale's date separator even with blanks in between that somehow could be interpreted as a date was accepted as such, which was especially confusing with incomplete dates containing only 2 numbers that in many cases were meant as textual input instead. For example

  • In en-US locale, M/D is a valid date input to be interpreted as day of month of current year. However, M/D/ and M.D. were accepted as well.
  • In de-DE locale, D.M. is a valid date input to be interpreted as day of month of current year. However, D.M and D/M and D/M/ were accepted as well.

In case of an input like 1.2 in a de-DE locale or others using '.' separator, meant as some sort of textual numbering, this was extremely annoying, it was interpreted as 1st of February of current year and the user had to prepend a single quote / apostrophe to suppress date recognition. Similar for 1.2.3 in locales that do not use the '.' date separator.

Now, during build time for each locale one full date acceptance pattern is generated from the existing locale data's number format FormatElement with formatindex="21" that is also used to edit dates, taking the DMY order and the defined DateSeparator. For example, in the en-US locale this generates M/D/Y from the MM/DD/YYYY FormatCode, and in the de-DE locale D.M.Y from the DD.MM.YYYY code. For this to work correctly the separator used in the FormatCode must match the DateSeparator element defined in Separators. As for all rules there's one exception though ;) if the format code uses a different separator and that is one of the known '-' '.' '/' separators, a second pattern is generated using the format's separator. This as a generalized case for locales that for example may use an ISO 8601 edit format, as hu-HU does, regardless what the date separator is defined to.

Additionally to the date acceptance pattern every locale of course still accepts input in an ISO 8601 Y-M-D pattern, and since LibreOffice 3.5 that also leads to the YYYY-MM-DD format being applied.

Localizers, HEADS UP please

If in your locale incomplete dates should be accepted or additional patterns that vary from the generated full date pattern are needed, those are to be defined in the locale data LC_FORMAT element for which a new DateAcceptancePattern element exists, of which zero or more can occur before the FormatElement elements. Currently only the following patterns are defined as they are the only ones I knew were plausible:

  • bg-BG, a trailing breaking or non-breaking space followed by lower case or upper case Cyrillic letter GHE and a dot, as defined in the edit format
    • D.M.Y г.
    • D.M.Y г.
    • D.M.Y Г.
    • D.M.Y Г.
  • de-DE, incomplete date
    • D.M.
  • en-US, incomplete date
    • M/D
  • sl-SI, date separator dot plus space
    • D. M. Y

For example see i18npool/source/localedata/data/en_US.xml

Happy date accepting :-)

Update: an updated list of locales and patterns is available in a newer blog post.