Hi Don, Thanks for the input.
Is this also using a string literal after the format string, like " / hour" ? And if so, even if the formatting isn't messed up, is there a space between the number specifier and the string literal, like #,###.00 " / hour" or has the space been put inside the string literal, like #,###.00" /hour" I suspect the space issue is not region specific, but just isn't immediately apparent on US versions, so would be interested to hear if it is happening or not with your documents. Thanks Paul On Thu, 12 Sep 2013 22:41:50 -0400 Don Myers <[email protected]> wrote: > Hi, > > I'm running LO 4.1.1.2 (Document Foundation Version) in Ubuntu 13.04. > After reading about this issue, I tried some spreadsheets going back > a number of years, mostly .ods, and one .sxc, and all of the formulas > saved in them are working perfectly. This is in the US. I also tried > some new formulas using existing data in the spreadsheet, and they > work fine also. > > Don > > > > On 09/12/2013 08:54 PM, Paul wrote: > > Hi Regina, All, > > > > I've finally (finally!) updated LO, and checked this problem again, > > and it still manifests. I can confirm that it manifests with the > > following LO versions: > > > > 4.0.3.3 > > 4.0.5.2 > > 4.1.1.2 > > > > This is with a locale of South Africa, but I think that just makes > > the problem worse by confusing some of the characters in the string > > "hour" with locale specific currency symbols; the underlying > > problem has to do with not preserving the space before the quoted > > string literal in the format string over saves, which is not a > > locale specific problem, as far as I can see. > > > > Can anybody confirm this and give their LO version and locale? > > > > Should I file a bug report, and if so how do I go about doing that? > > When I first looked at filing a bug, I found both > > https://bugs.freedesktop.org/ and > > https://www.libreoffice.org/get-help/bug/. Which is the currently > > preferred bugtracker? > > > > Thanks for the assistance so far > > > > Paul > > > > > > On Fri, 19 Jul 2013 15:07:20 +0200 > > Paul <[email protected]> wrote: > > > >> Hi All, > >> > >> Haven't had a chance to test in LO 4.1 beta, but I was hoping > >> someone could at least confirm that they are getting the same > >> results in 4.0 or prior, and maybe even someone with 4.1 could > >> comment on if it is still happening. > >> > >> Anybody? > >> > >> Regina, you said you weren't getting the weird formatting in your > >> version, but can you confirm the behaviour as regards the moving of > >> the space in your version? > >> > >> Many thanks > >> > >> Paul > >> > >> > >> > >> On Wed, 10 Jul 2013 02:11:26 +0200 > >> Paul <[email protected]> wrote: > >> > >>> Hi Regina, > >>> > >>> Terribly sorry about the delay in following up on your > >>> suggestions. I didn't mean to just disappear like that. It's been > >>> a bit hectic here, and I haven't had time to try with LibreOffice > >>> 4.1 beta yet, but I've tried a couple of other things. > >>> > >>> Firstly, I tried formatting the cell as a plain number, with > >>> ' " / hour"' after the default format, so the complete format is > >>> #,###.00 " / hour" > >>> > >>> This got changed over the save to > >>> #,###.00" / hour" > >>> > >>> Again, the space was removed in front of the quotes, and added > >>> behind. Other than that, the "hour" wasn't mangled, I'm assuming > >>> that the mangling is only because of interpreting it as currency > >>> symbols. > >>> > >>> When I removed the extra space behind the quotes, but left it > >>> without a space in front, it preserved that over saves, i.e. the > >>> following worked fine over saves > >>> #,###.00" / hour" > >>> > >>> This is still rejected when I change to currency format. > >>> > >>> Next, I looked at my locale settings. Under Tools|Options|Language > >>> Settings|Languages I have the following: > >>> Language of > >>> User interface: Default - English (USA) > >>> Locale setting: Default - English (South Africa) > >>> Decimal separator key: checked : Same as locale setting (.) > >>> Default currency: Default - ZAR > >>> Date acceptance patterns: Y/M/D;M/D > >>> Default languages for documents > >>> Western: English (South Africa) > >>> Asian: greyed out : Default - Chinese (simplified) > >>> CTL: greyed out : Default - Hindi > >>> For the current document only: not checked > >>> Enhanced language support > >>> Show UI elements for East Asian writings: not checked > >>> Show UI elements for Bi-Directional writing: not checked > >>> Ignore system input language: not checked > >>> > >>> I tried changing the default locale setting to "English (USA)", > >>> which also changed the currency and date settings. When I added ' > >>> " / hour"' it again moved the space from in front of the quotes to > >>> inside the quotes over saves. But now this doesn't mangle > >>> anything, I'm guessing because it's using a dollar sign instead > >>> of an "R" as the currency symbol. Changing the symbol to "R" by > >>> changing the format code from "[$$-409]" to "[$R-409]" works if > >>> the locale is "English (USA)". When the locale is "Default - > >>> English (South Africa)", changing the currency symbol by changing > >>> "[$R-1C09]" to "[$$-1C09]" doesn't help matters. > >>> > >>> I also noticed that with a space either in front of the quotes or > >>> moved inside the quotes to give a double space before the slash, > >>> two spaces are shown before the slash in the actual cell. So the > >>> only way to get only one space between the number and the slash > >>> in the cell is to have only one space, either in front of the > >>> qoutes or inside the quotes, but not both. > >>> > >>> It feels like there are two bugs, the first is that over saves LO > >>> doesn't preserve the space before the quotes, and moves it inside > >>> the quotes, irrespective of locale, and the second is that when > >>> there is no space before the quotes, the letters inside the quotes > >>> get interpreted as control codes instead of as literal text, and > >>> this interpretation depends on locale. > >>> > >>> There was also some strange behavior when entering just a plain > >>> number format, not currency. If I tried to enter a new number > >>> format by adding spaces inside the quotes, without a space in > >>> front of the quotes, say by setting the format to '#,###.00" / > >>> hour"' and then adding spaces to make it '#,###.00" / hour"', > >>> the moment it became a new format (one I hadn't used before), the > >>> preview changed to just displaying the number, without any > >>> formatting, and if I clicked OK, this carried over to the cell > >>> and reset the format to '#,##0 ;(#,##0)'. If, however, I didn't > >>> click OK when the preview reset, and instead added a space before > >>> the quotes, the preview suddenly became correct, and I could then > >>> remove the space in front of the quotes and it would stay > >>> correct. Once I pressed OK this format would get saved, and I > >>> could use it again without it getting messed up. Likewise if I > >>> added a format with, say, 5 spaces in the quotes and no space > >>> before the quotes, in this way, then went to cell formatting > >>> again and removed a space to four spaces, this didn't get messed > >>> up. But if I removed another space, to 3 spaces, which is a > >>> format I had previously used, then added a space, the format > >>> would get messed up again. It seems that there is some format > >>> interpretation going on behind the scenes when a space is added > >>> that is not going on when a space is removed. > >>> > >>> I think someone needs to have a careful look at how this section > >>> of the code is operating, there are subtle bugs in it. > >>> > >>> I will try to install the beta as soon as I can, and will test > >>> again and report back. > >>> > >>> Thanks again for the help > >>> > >>> Paul > >>> > >> > > > -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
