Using version 5.0.3 on windows, boxplots can take an optional 4th column which contains a factor, causing it to draw one boxplot for each level. Also, spaces are allowed in columns, provided that the column is quoted. However, boxplots are not allowing this to occur in the factor.
Consider the following data set
a 1
a 2
a 3
a 4
a 5
b 1
b 3
b 5
b 7
b 9
We can plot this successfully with plot datafile u (0):2:(0):1 with boxplot and it will draw one boxplot for the value a and one for the value b. The behavior is as expected here. The result is in the attached png NoSpace.png.
Now consider this data set
a 1
a 2
a 3
a 4
a 5
"b c" 1
"b c" 3
"b c" 5
"b c" 7
"b c" 9
Here the same command does not work as expected (here the a's are not quoted, but quoting them as well produces the same result). It seems that the boxplot can not figure out that the values "b c" belong together, and it seems to treat each entry as a separate factor. The space is causing this, but it should be allowed as it is quoted. The result of the same plot command is attached as Space.png.
This doesn't seem to happen with current CVS (5.1)
I get the attached output
I suppose it got fixed as a side effect of something else, but I don't know what.
Testing it out with the development version that I built on May 1st, I am also seeing it fixed. So I guess this report can be closed, as it has already been fixed.
I wouldn't mind back-porting a fix to 5.0, but first we have to figure out what exactly fixed it. I suppose there's always bisection-by-date...
There is a mystery lurking here. The fix came from a patchset applied in Jan 2015. Supposedly this same patchset was also applied to 5.0. It is in the ChangeLog, in the NEWS and release notes for 5.0.1, and the patchset itself is in my archive with a date of 07-Jan-2015. But the code is not in the CVS repository for 5.0. I cannot explain that. Could that one day of updates have been lost in a SourceForge meltdown? There were several in that time frame.
Anyhow, I have found the relevant patchset and will test that it still works when applied to 5.0.3.
I don't believe any data was lost at SF. Both the RCS archives and the check-in mail archive indicate that there simply was never any check-in of the code for this patch to the 5-0 branch.
The check-in of NEWS and ChangeLog is there, which would tend to indicate that no data was lost at SF's end. You simply forgot to check in the actual source change ;-)