GNOME Bugzilla – Bug 656056
Incorrect creation of scientific format
Last modified: 2011-08-08 16:37:02 UTC
Breakpoint 2, odf_scientific (xin=0xbfffdbd8, attrs=0x87b35e8) at openoffice-read.c:4052 4052 go_format_generate_str (state->cur_format.accum, details); (gdb) p *details $2 = {family = GO_FORMAT_SCIENTIFIC, magic = GO_FORMAT_MAGIC_NONE, min_digits = 1, num_decimals = 2, thousands_sep = 0, negative_red = 0, negative_paren = 0, currency = 0x0, force_quoted = 0, exponent_step = 1, exponent_digits = 4, use_markup = 1, simplify_mantissa = 0, expansion = { 0 <repeats 30 times>}} (gdb) p state->cur_format.accum->str $4 = (gchar *) 0x87b3a50 "" (gdb) n [Thread 0xb3200b70 (LWP 2445) exited] 4054 go_format_details_free (details); (gdb) p state->cur_format.accum->str $5 = (gchar *) 0x87b3a50 "0.00EE0" Note that exponent_digits = 4 but the created format string does not reflect that!
Created attachment 193328 [details] sample file Both cells should have 4 digits in the exponent. In the use_markup=TRUE case this fails.
The code makes it look intentional, but why? We have: if (details->use_markup) g_string_append (dst, "EE0"); else { /* Maximum not terribly important. */ int digits = CLAMP (details->exponent_digits, 1, 10); g_string_append (dst, "E+"); go_string_append_c_n (dst, '0', digits); } I think this should just be: int digits; if (details->use_markup) g_string_append_c (dst, 'E'); /* Maximum not terribly important. */ digits = CLAMP (details->exponent_digits, 1, 10); g_string_append (dst, "E+"); go_string_append_c_n (dst, '0', digits);
That's in go_format_generate_scientific_str
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.