GNOME Bugzilla – Bug 662149
Hidden data, without a hint
Last modified: 2011-10-21 17:56:47 UTC
Created attachment 199373 [details] Screenshot of affected cell Here's a short user story: So, my boss tells me to send all of the "Fosmid Ends" to someone in Germany. I look at this spreadsheet (see screenshot), and don't see any "Fosmid Ends", just "Fosmid", "Fosmid Subclone", and other unrelated stuff. Ok, I think, every Fosmid and Fosmid Subclone has ends, just send them all. *BZZT*, wrong answer. This spreadsheet is from Excel, and apparently the fonts on linux are slightly larger than they are on windows, as the text that fits in the cell in Excel does not fit in the cell in Gnumeric. Ok, fine, that's acceptable, as nothing prevents someone from deliberately shrinking the column so that the text doesn't fit. What *really* hurts is that there's no indication that this has happened. Unless you *know* there's supposed to be another word there, you can't tell it's hidden except by clicking on the cell and looking up at the top of the window where the cell contents are displayed. If you could just change the cell somehow, to let a person know that there's something hidden there, my job would be less in jeopardy today. I think Excel puts coloured triangles in the corners of the cells, doesn't it? On a related note, is there *any* way to fix the fonts so that the spreadsheet looks the same on linux and windows? That contributed to this problem, but it also affects powerpoint files, word files, etc, etc and makes Linux(tm) look bad at the worst possible time, when you're showing it off to someone else. Thanks! (I'm using Fedora 14)
It is interesting screen shot. Apparently somebody intentionally fixed the height of row 11, otherwise the rest of "Fosmid Ends" would be visible in a second line and the row height would be increased. (At least that happens in the current development version. I don't know exactly which version of Gnumeric Fedora 14 has packaged.)
I have nearly finished a patch for this but in the presence of bug #662368 it is impossible to test properly. In fact I found bug #662368, bug #662361 and bug #662331 while testing this patch (and earlier versions of the patch).
I'm impressed by the speed of your work; wow! Thanks!
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. Note that since I find these markers quite annoying, they are by default switched off and need to be enabled in the view properties dialog.
Created attachment 199670 [details] Lame two-cell spreadsheet created by Excel 2008 for mac In Excel, it looks like "one two five six" when viewing and printing. In Gnumeric 1.10.17, you can see "one two tfive six", almost.
Which is more annoying, almost-invisible small markers, or errors with career implications due to hidden text? It's true we don't have robust statistics on this, but we do have proof that it is non-zero (Bug 662149). I didn't know that the markers could be turned on (or that Gnumeric even had them), and I'm not alone: I predict that only people who get bitten by this ever find out about the feature. *blush* I just checked Excel 2008 for mac, and it's got this problem too. A1: one two three four B1: five six "three four" is hidden on Excel, but opening the same file in Gnumeric you can see the edge of the "t" in three, so the font (Verdana 10) is smaller in Gnumeric, not larger. See attached. As an addendum, do you have any information about font sizes being different between operating systems and how to fix it, which contributed to this bug? 10pt should be the same number of pixels wide on all systems. Thanks.
Penelope, the markers did not exist until yesterday. I just added them to the development version, so they couldn't be turned on. I have just also added a preference setting so that you can have them always on by default. In our schemas the initial preference setting is not to show the markers but any distribution can easily change that. I do hope that users check out the preference settings that we provide. Fonts are a tricky issue, especially since the underlying libraries may substitute fonts if the requested ones don't exist and even the font rendering may change the size of a string slightly depending on the resolution and the quality settings. Within Gnumeric we try our best to ensure that the effective display does not change on resolution changes but if you switch between OSs that cannot work.