Apache OpenOffice (AOO) Bugzilla – Issue 106960
Thin Space (Unicode: U+2009) as Thousands Separator
Last modified: 2010-07-12 06:57:47 UTC
Proposal: Optional usage of the "Thin Space" (Unicode: U+2009) as thousands separator and/or digit group separator. Motivation: First of all the thin space as a thousands separator looks very nice. :) Second, the usage of commas or periods as a thousand separator can lead to confusion when (printed) documents are exchanged between countries with different usages of commas and periods. Thus commas and periods should be avoided as a digit group separator, instead (preferable) the "Thin space" should be used, which is also recommended in ISO 31-0. References: http://en.wikipedia.org/wiki/Space_(punctuation)#Table_of_spaces : "U+2009   Thin Space General Punctuation ] [ One fifth (sometimes one sixth) of an em wide. Recommended for use as a thousands separator for measures made with SI units. Unlike U+2002 to U+2008, its width may get adjusted in typesetting." http://en.wikipedia.org/wiki/SI_units#SI_writing_style : "Spaces may be used as a thousands separator (1000000) in contrast to commas or periods (1,000,000 or 1.000.000) in order to reduce confusion resulting from the variation between these forms in different countries. In print, the space used for this purpose is typically narrower than that between words (commonly a thin space)." http://en.wikipedia.org/wiki/Thousands_separator#Digit_grouping "... Therefore the space is recommended in the SI/ISO 31-0 standard,[8] and the International Bureau of Weights and Measures states that "for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three".[9] ..." http://en.wikipedia.org/wiki/ISO_31-0#Numbers : "Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. For this reason, ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign."
Arguments against this enhancement. 1) Your "looks very" nice. The fact you added a smiley at the end tells me you will understand that your argument is highly subjective and thus not an argument :) I could say "it's ugly" without further detail: +1 + -1 =0 (BTW: I am native of country where the space - thin or not - IS the norm as thousand separator. So that one cannot accuse me of being biased when I advocate against your proposal. ;) ) Now the real argumentation... 2) "separator can lead to confusion when (printed) documents are exchanged between countries with different usages of commas and periods" Here and in the rest of your motivation I see an attempt to say "this world with many different - and sometimes even contradictory - languages, cultures and usages makes exchanges complicated and might even lead to errors. Let's adopt a common way of communicating, standardizing...". <sigh> That's a big question I don't want to discuss here. I consider this also as not a good argument because I tend to prefer culture heterogeneity to technical ease of use. In other words, the machine has to adapt to the people, not the contrary. But ok, you speak about "optional" use... But there I ask myself: why should we (software makers) respect locales and standards if we give the user the possibility to break those standards? 3) Technical argumentation. a) AFAIK the Unicode U+2009 character is not available in a majority of fonts thus you would get 1000000 or maybe even 1?000?000 in some cases. b) The Unicode U+2009 is a breaking space. Thus, you will get in some cases: 1 000<end of line> 000 Especially for the 2 last reasons I'd like to close this issue as WONTFIX. Though, if you want, I'd like to invite you to discuss this further (and first of all the motivation of your proposal) on discuss@ux.openoffice.org.
Closed
Reopened
Hello es, I skip the first point and go directly to the real argumentation: 2) es wrote: > "Here and in the rest of your motivation I see an attempt to say "this world ..." You may see this point, but it is totally not mine. After all this is just a feature request for one of the many office applications out there. In the following points you are contradicting yourself IMHO: > "In other words, the machine has to adapt to the people, not the contrary." ... > "... why should we (software makers) respect locales and standards if we give the user the possibility to break those standards?" Because giving not the possibility would, in fact, imply people have to adopt to the "machine". Also in 1) you mention your locale has spaces as thousands separators. This fact (almost) makes the whole discussion obsolete, because this means OOo should have/had this possibility already in the fist place! (In order to maintain / not break locale standards.) So, up to here I would say we both agree on the need of this feature (?). 3) I really overlooked the fact that Thin Space (U+2009) is a breaking space, however there are several solutions: - Instead of the Thin Space the Narrow No-Break Space (U+202F) character could be used. - The Thin Space could be used in combination with two (each on a side) Word Joiner (U+2060) characters. I don't know how widespread these characters are, as per Wikipedia these characters were introduced with Unicode 3.0 (in 1999) and Unicode 3.2 (in 2002), respectively. So IMO chances are they will be more widespread in the (near?) future (as OOo itself hopefully too). On the other hand, since this feature will hopefully be optional, the user can change the thousands separator any time, in case he is bound to an incompatible font.
@famo: I re-read your first and last comments and there's something I completly overlooked: You have filed this issue to the "UI" component. So a very "visual" and general stuff concerning most of the time the display and look&feel of OOo (dialogs, toolbars, appearance...). So now I don't understand your report anymore :( Please mention very concrete occurrences of what you describe: where should what look how when you do what? (Ex: - importing a csv in Calc - Dialog view and data insertion? - inserting a formatted field in Writer? - AutoCorrection in Writer tables - ...?) :) To your other comments I can give you an answer at rhetorical level even if I missed the full content: :) > In the following points you are contradicting yourself IMHO:... >> "In other words, the machine has to adapt to the people, not the contrary." ... >> "... why should we (software makers) respect locales and standards if we give the user the possibility to break those standards?" No I don't :) Because with "standards" I didn't mean "computer standards" but "locale standards" which pre-existed when the computer technology decided to translate them - maybe with bugs? - for the machine. I meant standards defined by country governments (so let's talk about "humans"), not the interpretation of those made by non-native computer specialists. Your request sounds to me right now like: "I want to use your grammar checker but I want it not to mark 'he doesn't know *no*thing' as correct"... -> contradiction In other words: it sounds to me as if you want a software to give you the opportunity to overrule human rules (grammar/decimal sign/thousand separator) with your own (as person) needs. Am I wrong? > Also in 1) you mention your locale has spaces as thousands separators. > This fact (almost) makes the whole discussion obsolete, because this means OOo > should have/had this possibility already in the fist place! (In order to > maintain / not break locale standards.) It does have! If you have the correct locale (while importing, in the UI... or whatever... it depends of what you mean - "what, where, when"...) Once again: please give concrete examples. 3) To your alternative proposals: we will discuss this further when we will have first defined "what, where, when" :) I'd like to stress followings: - My "feeling" is (Just "feeling" because I know now I might not have fully understood you) that your request is not an improvement but a regression. - But the way you express it is worth of a discussion. - That I should normally reassign to the general "requirements" pile where it might remain untouched during decades... - And that I'd like your proposal to be seriously analyzed before that term. :) So once again: please expose this again on discuss@ux.openoffice.org. There, you will get real time attention from very different people but all committed in improving our software.
Sum up: this issue does not only depends on issue 106961, this is somehow a duplicate of it. If we give the user the opportunity to choose his own separator (issue 106961), the UI will probably be an edit field. The character can then be entered vie context menu - Special character. With all drawbacks discussed here about U+2009 (breaking space, not broadly supported) U+202F (not broadly supported) it sounds better not to complicate the UI with predefined defaults (i.e. in a list box): "',' Comma '.' Point ' ' Narrow No-Break Space ' ' Thin Space ..." ... which is not directly understandable and would give most of the time broken results. Let's stuck to the summary of issue 106961 ("own liking") and let's not define defaults. *** This issue has been marked as a duplicate of 106961 ***
closed