Bug 137692
| Summary: | [x86_64] gnumeric picks up unprintable characters | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||||||
| Component: | gnumeric | Assignee: | Caolan McNamara <caolanm> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | |||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 3 | CC: | terra | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | FC3 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2004-11-09 18:28:55 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 105981 [details]
a sample Excel file which demonstrates the issue
Opening the same .xls file in 'oocalc' one is not getting extra "appendages" in spreadsheet fields. An embedded graph looks much worse, though. I found also that if one does some edits to a demo file, say removing unwanted "characters" and will attempt to save results in the same format as the original then gnumeric will spit on a screen a lot of mesages like ** (gnumeric:13415): WARNING **: This is somewhat corrupt. We already wrote a length for a string that is being truncated due to encoding problems. Leaking gnm-format at 0x9e1200 [General]. ** (gnumeric:13415): CRITICAL **: file go-font.c: line 33 (go_font_free): assertion `font->ref_count == 1' failed and it will stop. Whatever was saved it cannot be reloaded because of "Unsupported file format". With some other file and similar operations (edit and save in the original format) one can get: ...... ** (gnumeric:13489): WARNING **: hmm we could not represent character 0xffffffff, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0xffffffff, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x30, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. ** (gnumeric:13489): WARNING **: hmm we could not represent character 0x0, skipping it. Segmentation fault and only an empty file like .gsf-save-akPsV0 will show up. Created attachment 105984 [details] An Excel file which is causing segmentation fault This is a sample file to crash gnumeric in a way described in comment #3. It seems that what will happen is a particular sample dependent; but even if a save after edit-out succeeded then "garbage characters" are back in a saved material. Ouch! I should have thought about that earlier. All the trouble above happens on x86_64 but not x86. This rather clearly points out where bugs may be and also why oocalc does not have problems. :-) OTOH older gnumeric versions did work on Alpha ... Possibly a type error in ms_biff_get_chars. Can we get a compilation log for gnumeric on x86_64, please? Created attachment 106041 [details]
x86_64 compilation log
Created attachment 106042 [details]
ia64 log
fixed in gnumeric 1.3.92 backported to rawhide and fc3 Should be good in gnumeric-1.2.13-8.fc3 In all my test cases gnumeric-1.2.13-9 from rawhide, actually recompiled to work with python-2.4-0.b2.3, behaves on x86_64 without any nasty surprises (but see bug #138742 about recompilation issues). |
Description of problem: While reading .xls files produced by Excel gnumeric apparently "reaches" beyond a field width and picks up various unprintable characters. This is not only messing up display but affects also printouts, and other conversions, where some pieces of an expected printout vanish while some other characters, deemed obviously "printable", are messing up results. Earlier versions of gnumeric were lacking this "feature". Saving in a native gnumeric format helps to remove quite a bit of this garbage but, unfortunately, not all of it. Also when saved as LaTeX file this ends up with results which are causing complaints "Keyboard character used is undefined .... l.242 ...Velvia Reciprocity Correction^^A^^B^^F}}}" and the like. One has to run results through a filter of tr -dc '[:print:]\n' kind before achieving something close to a LaTeX source file. All in all a serious PITA. Version-Release number of selected component (if applicable): gnumeric-1.2.13-6 How reproducible: On all .xls files I tried so far