Can't insert any PNG image into document: unknown format error. Can view and open in any other editor, viewer.
I can't reproduce. Version: 6.2.4.1 (x64) Build ID: 170a9c04e0ad25cd937fc7a913bb06bf8c75c11d CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: threaded Please can you attach a png that shows the issue.
I have Linux, openSUSE. Reproducible with any PNG I have. Sample attaching.
Created attachment 151681 [details] SPB.png
Version: 6.2.3.2 Build ID: 20(Build:2) CPU threads: 8; ОС:Linux 5.1; UI render: GL; VCL: kde5; Locale: ru-RU (ru_RU.UTF-8); UI-Language: ru-RU Calc: threaded
Unconfirmed on mint 19.1 x64 with Version: 6.3.0.0.alpha1+ Build ID: 40e2a0d7039eee9c5377996da3949680903e1016 CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-22_13:55:35 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Yes works with gtk3 VCL: Версия: 6.2.3.2 ID сборки: 20(Build:2) Потоков ЦП: 8; ОС:Linux 5.1; Отрисовка ИП: GL; VCL: gtk3; Локаль: ru-RU (ru_RU.UTF-8); Язык UI: ru-RU Calc: threaded Problem only with qt5. Seems multiple issues with qt5: https://bugs.documentfoundation.org/show_bug.cgi?id=125482
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
(In reply to Xisco Faulí from comment #7) > Could you please try to reproduce it with a master build from > http://dev-builds.libreoffice.org/daily/master/ ? Yes, bug still present in 6.3 with KDE integration.
Created attachment 151723 [details] Screencast that shows insertion of PNG image Works fine for me with Version: 6.3.0.0.alpha1+ Build ID: e81da6e2a8fdb28d53f402c58248cb083164d315 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded see attached screencast. Are the steps taken there the same that you are taking? Setting back to UNCONFIRMED, since NEW is only set if the bug has been confirmed by somebody else in addition to the reporter.
(In reply to Michael Weghorn from comment #9) > Created attachment 151723 [details] > Screencast that shows insertion of PNG image > Works fine for me with > Version: 6.3.0.0.alpha1+ > see attached screencast. > Are the steps taken there the same that you are taking? Yes, exactly same steps shows for me unknown format dialog, nothing inserted.
Is that PNG file located in some directory with a "special" path? Does it work if you put it into /tmp/. Also, does it happen with a fresh user profile, e.g. if you run LO with libreoffice -env:UserInstallation=file:///tmp/test123
(In reply to Michael Weghorn from comment #11) > Is that PNG file located in some directory with a "special" path? No, not special: ~/Pictures (Cyrillic chars path here). > Does it work if you put it into /tmp/. Yes, works fine if open same file from /tmp > Also, does it happen with a fresh user profile, e.g. if you run LO with > libreoffice -env:UserInstallation=file:///tmp/test123 Yes, error reproducible opening file from Cyrillic path, works fine from /tmp P.S. Strange starts to work fine today. With my regular profile, stable reproducible only with fresh user profile. as above. Weird: KDE or openSUSE bug?
(In reply to tantrido from comment #12) > (In reply to Michael Weghorn from comment #11) > > Is that PNG file located in some directory with a "special" path? > No, not special: ~/Pictures (Cyrillic chars path here). Can you paste the whole path for one that fails, including the Cyrillic chars? I'll try to reproduce with such a path and a clean profile on my Debian testing then. > P.S. Strange starts to work fine today. With my regular profile, stable > reproducible only with fresh user profile. as above. Weird: KDE or openSUSE > bug? That's hard to tell. Does this work as expected when you use A) "File" -> "Open" from LibreOffice with a file in such a directory? B) "File" -> "Open" from another KDE application, e.g. kate?
(In reply to Michael Weghorn from comment #13) > Can you paste the whole path for one that fails, including the Cyrillic > chars? ~/Картинки/Питер.png > > P.S. Strange starts to work fine today. With my regular profile, stable > > reproducible only with fresh user profile. as above. Weird: KDE or openSUSE > > bug? > > That's hard to tell. Does this work as expected when you use > A) "File" -> "Open" from LibreOffice with a file in such a directory? No can't open, but error is different: it adds 8 question marks to the file name and says file does not exists like in Bug 125482 (reopened). > B) "File" -> "Open" from another KDE application, e.g. kate? All other KDE apps work fine, so definitely kde/qt integration bug (probably related only for Cyrillic case).
Created attachment 151756 [details] File does not exist dialog
'~/Картинки/Питер.png' still works for me with a current master build and a fresh user profile. Is the issue also there for you with '/tmp/Картинки/Питер.png'? Also, can you please paste the output of the command 'locale'?
(In reply to Michael Weghorn from comment #16) > Is the issue also there for you with '/tmp/Картинки/Питер.png'? Opens fine from there. > Also, can you please paste the output of the command 'locale'? LANG=ru_RU.UTF-8 LC_CTYPE="ru_RU.UTF-8" LC_NUMERIC=C LC_TIME="ru_RU.UTF-8" LC_COLLATE="ru_RU.UTF-8" LC_MONETARY="ru_RU.UTF-8" LC_MESSAGES="ru_RU.UTF-8" LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL=
(In reply to tantrido from comment #17) > (In reply to Michael Weghorn from comment #16) > > Is the issue also there for you with '/tmp/Картинки/Питер.png'? > Opens fine from there. This is unexpected... I cannot reproduce with '/home/aleksey/Картинки/Питер.png' (after creating a dummy "home directory" for non-existing user aleksey on my system) either, though. Could you possibly experiment a bit whether you can find some path underneath /tmp/ that also breaks in your case? Are there possibly any unusual permissions set on the file/directory? What do these commands show: A) ls -lad '/home/aleksey/Картинки/' B) ls -la '/home/aleksey/Картинки/Питер.png' Does anything change if you start LibreOffice with env variable "LC_ALL=C.UTF-8" set?
(In reply to tantrido from comment #12) > Weird: KDE or openSUSE bug? Second. Please try retest your problem with LibreOffice from official site
(In reply to Michael Weghorn from comment #18) > Are there possibly any unusual permissions set on the file/directory? > What do these commands show: Nothing unusual - read-write. As I said also reproducible for any other png in other paths. > Does anything change if you start LibreOffice with env variable > "LC_ALL=C.UTF-8" set? Same error. Opens fine however if I select it via recent files menu. So assume could be caused by file open dialog. Seems there were similar issues in old KDE versions or in Firefox KDE integration. Reproducible in latest ver as well.
(In reply to tantrido from comment #20) > Nothing unusual - read-write. As I said also reproducible for any other png > in other paths. Can you try to find a path underneath /tmp/ for which this also happens?
(In reply to Michael Weghorn from comment #21) > (In reply to tantrido from comment #20) > > Nothing unusual - read-write. As I said also reproducible for any other png > > in other paths. > > Can you try to find a path underneath /tmp/ for which this also happens? Can't, works fine in any /tmp.
Also with regard to bug 125482, this sounds like some KDE or Qt bug. Or LO is corrupting memory in some way. (In reply to tantrido from comment #5 of bug 125482) > Weird. Now I have this bug with gtk3 as well. Only when opening via file > manager - Dolphin. Can open file via menu File->Open or via another file > manager. In the case of dolphin no KDE integration is involved, as LO will get this file as a parameter. The question marks sound like a memory corruption or wrong encoding. What happens if you start LO from the terminal via "SAL_USE_VCLPLUGIN=qt5 soffice" and then try to use the open dialog? This way no KDE should be involved (just check the About dialog that it says qt5, not kde5). If that has the same problem but not gtk3, then it sounds very much like a Qt bug. I guess it also happens with normal files, like described in bug 125482. What happens if you open a file via terminal? Either via directly calling "soffice <filename>" or via "xdg-open <filename>"?
Today works fine with either integration: qt5 or kde. Weird, not always reproducible.
(In reply to tantrido from comment #24) > Today works fine with either integration: qt5 or kde. Weird, not always > reproducible. Tandrido, did the problem occur again, or not? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still there. I propose to change it to RESOLVED WORKSFORME, if you're no longer able to reproduce it (you can reopen bug later, if it should happen again).
Dear tantrido, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear tantrido, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp