GNOME Bugzilla – Bug 686471
# ?pi/?? format misrendering
Last modified: 2012-11-15 22:17:07 UTC
Created attachment 226831 [details] Current output In tests/chart-fill-tests.gnumeric, axis labels using the ?pi/?? format don't look good at 0 and pi. They are displayed as 0pi/1 and pi/1, instead of 0 and pi.
This is not charting specific. Looks like a format issue.
Definitely format. Probably not new.
For fractions without the pi we have for format ?/??: 1 --> 1/1 0 --> 0/1 2 --> 2/1 I am not sure what formatting result do we want.
For regular (no-pi) fractions ?/?? Excel 2010 does the same as Gnumeric. Emmanuel, I am pretty sure that you really want: # ?pi/?? I would say that this is not a bug! But that the user is using the incorrect format.
I don't know if the format string is correct or not. It used to do what I want, ie: 0 and
Arrhhh, it looks like bugzilla doesn't like utf8 characters. The end of my message was: 0 and pi for angles equal to 0° and 180°. What is the correct format string that does that.
As I suggested in comment #4 you may want to try # ?pi/??
It doesn't work with gnumeric head.
If you enter =pi() in a Gnumeric cell and format it as # ?pi/?? What do you get in that cell?
Created attachment 229003 [details] result of "# ?pi/??"
Created attachment 229006 [details] screen shot I get something different with Gnumeric and goffice head.
A rounding issue ?
I cannot imagine how this could be a rounding issue. And I get the same some result with 3.14 as for =pi().
Created attachment 229016 [details] screen shot of fraction tab of format dialog Emmanuel, do you get the same result if you use the fraction tab of the format dialog as shown in this screen shot rather than type in the format string?
Strange: it is a locale issue. I can replicate by switching to a french locale! If I create the file in the French locale, save it and open in Canadian English locale I still see pi/1 and the format string is #\ ??\ pi/?? Specifically, there is no regular space following the # sign!
The locale string we show in the gui (and thus what was entered) is localized. We delocalize it to get the actual format used. Now, if " " is the locale's decimal separator (unlikely) or the locale's thousand separator (possible) then I get see localization/delocalization messing things up. This probably isn't the best tested code! What does =TEXT(PI(),"# ?pi/??") produce?
In Canadian English locale =TEXT(PI(),"# ?pi/??") yields pi In French locale =TEXT(PI();"# ?pi/??") yields pi/1 If I use the fraction tab to construct the "# ?pi/??" format and save it into a Gnumeric file, then the file content depends on the locale used: in Canadian English locale: <gnm:Style HAlign="GNM_HALIGN_GENERAL" VAlign="GNM_VALIGN_BOTTOM" WrapText="0" ShrinkToFit="0" Rotation="0" Shade="0" Indent="0" Locked="1" Hidden="0" Fore="0:0:0" Back="FFFF:FFFF:FFFF" PatternColor="0:0:0" Format="# ?? pi/??"> <gnm:Font Unit="10" Bold="0" Italic="0" Underline="0" StrikeThrough="0" Script="0">Sans</gnm:Font> </gnm:Style> in French locale: <gnm:Style HAlign="GNM_HALIGN_GENERAL" VAlign="GNM_VALIGN_BOTTOM" WrapText="0" ShrinkToFit="0" Rotation="0" Shade="0" Indent="0" Locked="1" Hidden="0" Fore="0:0:0" Back="FFFF:FFFF:FFFF" PatternColor="0:0:0" Format="#\ ??\ pi/??"> <gnm:Font Unit="10" Bold="0" Italic="0" Underline="0" StrikeThrough="0" Script="0">Sans</gnm:Font> </gnm:Style>
In the french locale " " is the thousand separator.
Some more info. In English locale, I put =TEXT(PI(),"# ?pi/??"): into a A1 and saved it as a file. I then opened the file in Canadian English locale: Executing # ?pi/?? OP_NUM_FRACTION_SCALE_PI OP_NUM_FRACTION 1 0 2 OP_NUM_VAL_SIGN OP_NUM_FRACTION_WHOLE OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_CHAR ' ' OP_NUM_DIGIT_1 '#' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_CHAR '
Some more info. In English locale, I put =TEXT(PI(),"# ?pi/??"): into a A1 and saved it as a file. Note that since bugzilla hates unicode characters I replaced the greek pi with the word pi below. I then opened the file in Canadian English locale: Executing # ?pi/?? OP_NUM_FRACTION_SCALE_PI OP_NUM_FRACTION 1 0 2 OP_NUM_VAL_SIGN OP_NUM_FRACTION_WHOLE OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_CHAR ' ' OP_NUM_DIGIT_1 '#' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_CHAR 'pi' OP_NUM_FRACTION_PI_SUM_START OP_CHAR ' ' OP_NUM_FRACTION_SIGN OP_CHAR ' ' OP_NUM_DISABLE_THOUSANDS OP_NUM_FRACTION_NOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DIGIT_1 '?' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_SLASH OP_CHAR 'pi' OP_CHAR '/' OP_NUM_FRACTION_DENOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DENUM_DIGIT_Q OP_NUM_DENUM_DIGIT_Q OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_ALIGN OP_NUM_FRACTION_BLANK_PI OP_NUM_FRACTION_SIMPLIFY_PI OP_NUM_FRACTION_SIMPLIFY_NUMERATOR_PI OP_NUM_FRACTION_BLANK_WHOLE OP_END I then opened it in French locale: Executing #,?pi/?? OP_NUM_FRACTION_SCALE_PI OP_NUM_FRACTION 0 0 2 OP_NUM_VAL_SIGN OP_NUM_DISABLE_THOUSANDS OP_NUM_FRACTION_NOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DIGIT_1 '?' OP_NUM_DIGIT_1 '#' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_SLASH OP_CHAR 'pi' OP_CHAR '/' OP_NUM_FRACTION_DENOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DENUM_DIGIT_Q OP_NUM_DENUM_DIGIT_Q OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_ALIGN OP_NUM_FRACTION_SIMPLIFY_NUMERATOR_PI OP_END So we seem to interpret the format string saved in the .gnumeric file as representing a localized string?!
All formats in .gnumeric go through make_format in xml-sax-read.c and thus through gnm_format_import which sends it to go_format_new_from_XL. go_format_new_from_XL takes an English format string. So the formats in .gnumeric are not localised. Whew! However, TEXT takes a localised format string and explicitly delocalises it before passing it to go_format_new_from_XL, so that gives the locale dependency you are observing. TEXT may thus not be the best way of investigating this problem.
Okay the good news is: if I create the format in English locale (using the fraction tab), save it in a file and then open it in French locale I get a format that behaves correctly. So there is a problem with the fraction tab interface (and I have some ideas).
No, I don't think it is a ui problem. Checking for localization/delocalization we have: Localize in : [# ?? pi/??] Localize out: [#\ ??\ pi/??] Delocalize in : [#\ ??\ pi/??] Delocalize out: [#\ ??\ pi/??] This is okay if [# ?? pi/??] and [#\ ??\ pi/??] would result in the same rendering, but: french: Executing #\ ??\ pi/?? OP_NUM_FRACTION_SCALE_PI OP_NUM_FRACTION 0 0 2 OP_NUM_VAL_SIGN OP_NUM_DISABLE_THOUSANDS OP_NUM_FRACTION_NOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_CHAR ' ' OP_NUM_DIGIT_1 '?' OP_NUM_DIGIT_1 '?' OP_CHAR ' ' OP_NUM_DIGIT_1 '#' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_SLASH OP_CHAR 'pi' OP_CHAR '/' OP_NUM_FRACTION_DENOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DENUM_DIGIT_Q OP_NUM_DENUM_DIGIT_Q OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_ALIGN OP_NUM_FRACTION_SIMPLIFY_NUMERATOR_PI OP_END english: Executing # ?? pi/?? OP_NUM_FRACTION_SCALE_PI OP_NUM_FRACTION 1 0 2 OP_NUM_VAL_SIGN OP_NUM_FRACTION_WHOLE OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_CHAR ' ' OP_NUM_DIGIT_1 '#' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_CHAR 'pi' OP_NUM_FRACTION_PI_SUM_START OP_CHAR ' ' OP_NUM_FRACTION_SIGN OP_CHAR ' ' OP_NUM_DISABLE_THOUSANDS OP_NUM_FRACTION_NOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_CHAR ' ' OP_NUM_DIGIT_1 '?' OP_NUM_DIGIT_1 '?' OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_SLASH OP_CHAR '
continued: pi' OP_CHAR '/' OP_NUM_FRACTION_DENOMINATOR OP_NUM_PRINTF_F 0 OP_NUM_SIGN OP_NUM_MOVETO_ONES OP_NUM_DENUM_DIGIT_Q OP_NUM_DENUM_DIGIT_Q OP_NUM_REST_WHOLE OP_NUM_APPEND_MODE OP_NUM_FRACTION_ALIGN OP_NUM_FRACTION_BLANK_PI OP_NUM_FRACTION_SIMPLIFY_PI OP_NUM_FRACTION_SIMPLIFY_NUMERATOR_PI OP_NUM_FRACTION_BLANK_WHOLE OP_END
We have two options here: 1) we can change the delocalization 2) we can change the program creation both are straightforward. Any preferences?
Created attachment 229091 [details] [review] proposed patch This proposed patch fixes the program creation.
Created attachment 229092 [details] [review] alternative (preferred) patch This patch changes the delocalization. I prefer it.
Excel accepts [#\ ??/??] as meaning the same as [# ??/??] so we should use the patch that fixes program creation ie. the first of these two patches.
On closer inspection of Excel's behaviour, Excel does not retain [#\ ??/??] but changes it to [# ??/??]. This is exactly the behaviour that the second patch would cause. I will be committing the second patch.
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. Emmanuel, if you find related issues please open a new bug.
PS: in French locale, if you create the format string by hand, it needs to be: #\ ??\ pi/?? since the space character is otherwise interpreted as a thousand separator.