GNOME Bugzilla – Bug 404264
Gnumeric removes initial whitespace when importing tab/space separated text
Last modified: 2007-02-10 16:06:52 UTC
I have files that begin with extra separators (for example \t at the beginning of the line). Gnumeric 1.7.6 removes these separators, regardless of whether the box "ignore initial separators" is checked or not. Gnumeric 1.7.6 is self compiled on AMD64. To reproduce 1)Open Gnumeric 2)Import attached file as Text Import 3)Select separated data 4)See Gnumeric correctly guess this is a tab-separated file Ignore initial separators is unchecked - all the columns line up based on number. 5)Press Forward - all initial separators are removed, messing up the alignment. 6)Press finish - messed up alignment is imported to Gnumeric Note that the mistake seems to happen only at stage 5.
Created attachment 81873 [details] Small test case for this bug
Okay, I've discovered this is supposed to be a feature - the last screen has a "Trim" button in the overall formatting. The default is Trim all. Switching it to neither fixes my problem. However, it seems like a minor UI bug to me: 1)Why are there separate options for ignore initial separators and trim? It would seem they have the same function - if I don't want to ignore initial separators, doesn't this automatically mean I DON'T want to trim? 2)If "Trim:" should exist as a separate button, shouldn't the default be "Don't trim" rather then trim both sides? Trim both sides causes me to lose data. Note: the default is to ignore, which would seem to imply you are cautious about losing data. Even if Trim exists as a separate button, I believe that the default of trim and "ignore" should be in the exact same manner.
"trim" is supposed to remove whitespace from each field after separation into fields. So there should not be any separators left to trim! So you may be seeing a real bug rather than a bad gui. (That's why "trim" is on teh format page.)
Created attachment 82082 [details] Text import with spaces There is another symptom which may or may not be related to the inital test case I've found. If it isn't I will open another bug, but since I think they're related, I'm attaching this now. This is a file with two space separated lines. 1)Import it into Gnumeric, using space as a separator (Gnumeric will automatically find comma as a separator, please chooose not to use it). 2)Check "see two adjacent separators as one" 3)Select "Trim neither" 4)Finish import 5)Search for space in the newly imported file. 6)Find *multiple* cells containing space. WHAT? One option is that the importer treats only a specific ASCII code as space, while search is more lenient. I'm not sure how to check that, but I thought it is an option.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report. We were trimming whitespace (for csv purposes). We shouldn't trim anything that happens to be separators.