Версия: 5.1.0.0.alpha1+ ID сборки: 8a334eb222906909bf77006687411ff9e03d9da3-GL TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-05_12:35:55 Локаль: ru-RU (ru_RU) variant №1 1. start LibreOffice 2. select "Open file" on Start Screen 3. Search and select your .gnumeric file 4. push key Open 5. file open in Writer as xml variant №2 1. open Calc 2. select File->Open 3. Search and select your .gnumeric file 4. push key Open 5. file open in Calc as text import in format xml. variant №3 1. open Calc or start LO 2. select File->Open 3. select type of file .gnumeric in drop-down list 4. Search and select your .gnumeric file 5. push key Open 6. file not open. will show an error message "total input error output"
Created attachment 119366 [details] test file gnumeric
I confirm it. Kubuntu 14.04
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. I noticed these kinds of logs: Throwing InvalidHeaderException warn:oox.storage:10807:1:oox/source/helper/zipstorage.cxx:66: ZipStorage::ZipStorage exception opening input storage: VisioDocument: version 0 Found xml parser severity error Document is empty
As I understand it, Markus Mohrhard made patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6726bdbd2143ae2875f3373b07b23611eb263d7 A log of the developers channel: [20:15:06] <tagezi> moggi: I am sorry for molestation. Do you saw this bug tdf#94834 ? [20:15:08] <IZBot> LibreOffice-filters and storage normal/medium NEW gnumeric import not work https://bugs.documentfoundation.org/show_bug.cgi?id=94834 [20:15:47] <moggi> tagezi: yes, but I'm picking the bugs that I want to fix [20:24:30] <tagezi> moggi: thank. I think that it is needed to be removed from from the ReleaseNotes, as in fact the new functional is not there, but there is only a new bug. thanks again From it I can conclude that Marcus is not interesting to get feedback or further development of this functional.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. It seems that indeed http://cgit.freedesktop.org/libreoffice/core/commit/?id=2db1e3447298f2b25287ff6ad4c5dda1e675f5e3 fixed this. I cherry-picked this to gerrit review for 5.0, see: https://gerrit.libreoffice.org/#/c/19296/
Markus: here is the bugtracker about https://gerrit.libreoffice.org/#/c/19296/ If it's your patch which fixed this, I don't know what it could be.
Closing as Julien said it was fixed and Marcus mention in 5.0 gerrit patch that it couldnt be backported.
(In reply to Yousuf (Jay) Philips from comment #7) > Closing as Julien said it was fixed and Marcus mention in 5.0 gerrit patch > that it couldnt be backported. check the facts fixes is not required or what? I'll wait Libre Office release date after 10/10/2015 and check himself
this bug is not fixed! Version: 5.1.0.0.alpha1+ (x64) ID build: 0b018d202dfcf4bb16b708e10085a4146243b0a0 TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-10-25_23:32:01 Locale: ru-RU (ru_RU) OS: Windows 7 HB x86-64
(In reply to kompilainenn from comment #0) > Версия: 5.1.0.0.alpha1+ > ID сборки: 8a334eb222906909bf77006687411ff9e03d9da3-GL > TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-05_12:35:55 > Локаль: ru-RU (ru_RU) > > variant №1 > > 1. start LibreOffice > 2. select "Open file" on Start Screen > 3. Search and select your .gnumeric file > 4. push key Open > 5. file open in Writer as xml > > variant №2 > > 1. open Calc > 2. select File->Open > 3. Search and select your .gnumeric file > 4. push key Open > 5. file open in Calc as text import in format xml. > > variant №3 > > 1. open Calc or start LO > 2. select File->Open > 3. select type of file .gnumeric in drop-down list > 4. Search and select your .gnumeric file > 5. push key Open > 6. file not open. will show an error message "total input error output" Reproduced. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 6da681442b17c723f9408a806e8d2367441ad65a TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-07_23:13:46 Locale: fi-FI (fi_FI)
Linux works perfectly. Ubuntu 15.10 64-bit Version: 5.1.0.0.alpha1+ Build ID: a148fe149c7af1995fd2aaab0a6e52242509b993 TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-11-08_23:54:51 Locale: en-US (en_US.UTF-8)
LO 5.2.0.2 on Windows 7 HB x86-64 repro
Bug confirmed using v5.2.1.1, v5.1.5.2 and v5.1.0.3 (current and first release in the 5.1 branch) under Windows 7 Pro x64 SP1 Confirmed with the provided file and any of my .gnumeric files. This featured announced in the 5.1 release never worked under the Windows OS Opening with File Open or drag-and-drop always results in a XML view in Writer and opening as a Gnumeric file always results in "General Error. General input/output error."
Debugging in VS (master build from ~two weeks ago) revealed that in: workdir\UnpackedTarball\liborcus\src\liborcus\format_detection.cpp GNUMERIC_ENABLED is not defined. Somehow liborcus is built without Gnumeric support on Windows.
(In reply to Aron Budea from comment #14) > Debugging in VS (master build from ~two weeks ago) revealed that in: > workdir\UnpackedTarball\liborcus\src\liborcus\format_detection.cpp > GNUMERIC_ENABLED is not defined. Somehow liborcus is built without Gnumeric > support on Windows. and? it can be easy to fix?
I tried to trace this down, since the issue itself seems to be trivial. However... GNUMERIC_ENABLED gets defined if __ORCUS_GNUMERIC is defined, and that gets defined in src/liborcus/Makefile.am if WITH_GNUMERIC_FILTER is defined. WITH_GNUMERIC_FILTER is defined during configure, and that's where I got lost, no clue what happens in there, and how it's called. LO repo's external/liborcus/* offered no clues, either, there's nothing related to Gnumeric. Markus, any suggestions on how to analyze this further? Or if it's a straightforward fix for an expert, don't mind me.
(In reply to Aron Budea from comment #17) > Markus, any suggestions on how to analyze this further? Or if it's a > straightforward fix for an expert, don't mind me. he does not want to correct this bug. he has star fever
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4462447b8a48ad097e56c47e3736d80dc4aaa13a tdf#94834 enable liborcus format detection on Windows It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #19) > David Tardon committed a patch related to this issue. > tdf#94834 enable liborcus format detection on Windows > > It will be available in 5.3.0. > will you backport this to 5.1 and 5.2?
David Tardon committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d65e40b6f44e97bbcc4c645b218c158669b638a2&h=libreoffice-5-2 tdf#94834 enable liborcus format detection on Windows It will be available in 5.2.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Unfortunately enabling gnumeric support in orcus was only part of the solution, now there's the following error during file open: "General Error. Generic input/output error." I can look into what's causing it in a few days.
I came across two strange issues in orcus: 1. It fails to find the file with name "Комп для Паши.gnumeric". This is where it throws an exception: https://gitlab.com/orcus/orcus/blob/master/src/parser/stream.cpp#L73 I assume the issue is the lack of Unicode filename-handling. 2. If file is renamed to ASCII characters, it proceeds further, but the string returned by the previous function is 11 bytes long, and the file still fails to load. Changing L67 as follows fixes this issue: std::ifstream file(filepath, std::ios::binary); https://gitlab.com/orcus/orcus/blob/master/src/parser/stream.cpp#L67
Bug report opened upstream.
Modified the Summary. The previous change could mislead people to think that it was a problem with a particular file. LibreOffice can't (never could) open ANY Gnumeric file under Windows.
Update using LibreOffice version 5.3.3.2: 1) the sample document still fails to open (as reported in Comment#23) 2) after renaming the file, the spreadsheet opens but doesn't show any content 3) any gnumeric file that I opened shows empty. This is a problematic situation! It could lead to people concluding that the content of the file was deleted. I think it is better to NOT open and show a message that LibreOffice can not open Gnumeric files (under Windows only?) than showing an EMPTY spreadsheet.
(In reply to Pedro from comment #26) > Update using LibreOffice version 5.3.3.2: > 1) the sample document still fails to open (as reported in Comment#23) > 2) after renaming the file, the spreadsheet opens but doesn't show any > content > 3) any gnumeric file that I opened shows empty. > > This is a problematic situation! It could lead to people concluding that the > content of the file was deleted. > > I think it is better to NOT open and show a message that LibreOffice can not > open Gnumeric files (under Windows only?) than showing an EMPTY spreadsheet. On Windows 10 + LO 5.3.3.2, I could open the file when renaming filename to have only ascii. Sheet 1 is empty but there's a sheet 2 which contain information. If I don't rename the file name, I can't open the file at least from Calc and got general input error message. So I don't reproduce your problem. Did you start from clean LO profile? Would you have other gnumeric example files we could test?
(In reply to Julien Nabet from comment #27) > On Windows 10 + LO 5.3.3.2, I could open the file when renaming filename to > have only ascii. Sheet 1 is empty but there's a sheet 2 which contain > information. > If I don't rename the file name, I can't open the file at least from Calc > and got general input error message. You are correct. The file is not empty. LibreOffice creates an empty Sheet1 that is displayed ontop of the existing sheets (so the document looks empty). This is not so bad but it is unexpected and could mislead users. > So I don't reproduce your problem. Did you start from clean LO profile? > Would you have other gnumeric example files we could test? I did test with an empty profile. The problem still occurs. I'm adding another sample file. In this case in addition to the previous problem it shows another LibreOffice import problem (the simple chart is not displayed).
Created attachment 133295 [details] Gnumeric spreadsheet with a single sheet with data and a bar chart When opening this sample with LibreOffice 5.3.3.2 under Windows 10, an empty Sheet1 is added before the original Gnumeric Sheet1 and the included chart is not displayed.
(In reply to Pedro from comment #29) > Created attachment 133295 [details] > Gnumeric spreadsheet with a single sheet with data and a bar chart > > When opening this sample with LibreOffice 5.3.3.2 under Windows 10, an empty > Sheet1 is added before the original Gnumeric Sheet1 and the included chart > is not displayed. Charts are not supported by orcus and therefore the gnumeric import right now.
Created attachment 133297 [details] Screenshot showing what file calc_with_chart.gnumeric looks like when opened in Gnumeric This is what is expected when opening the file in LibreOffice. A single Sheet1 with two data columns and a bar chart.
(In reply to Pedro from comment #31) > Created attachment 133297 [details] > Screenshot showing what file calc_with_chart.gnumeric looks like when opened > in Gnumeric > > This is what is expected when opening the file in LibreOffice. A single > Sheet1 with two data columns and a bar chart. See Markus' response just before your comment. The lib Orcus (used to import Gnumeric) doesn't support charts. So this part is either a wontfix or an enhancement.
The original issue has been fixed by David. Please don't reopen a bug report if the bug has been marked as fixed by a developer unless you can reproduce the bug with exactly the same steps as the original reporter. In this case the remaining issues are non-ascii file names which are a completely different problem and require a different solution.