Created attachment 142046 [details] ODT/ZIP arvhive content vizualization I insert PDF as image. I notice, that in ODT file (ZIP archive contained) it exist as both PDF and PNG. After some time I notice, that it loose quality while printing exporting - I find out that then image is stored as two identical PNG images. Note: name of second PNG is same as name of PDF in ODT/ZIP container. It is not easy to reproduce, but most consistently I can reproduce by: 1. Inserting PDF as image 2. Save file 3. Delete image. 4. Save file. 5. Insert another PNG image. 6. Save file. 7. Do undo until you see the first PDF image. 8. Save file. LibreOffice installed via RPMs from LibreOffice site. I use openSUSE Leap 42.3 Linux.
Created attachment 142047 [details] t1.odt - contains both versions of image: as original PDF and as PNG
Created attachment 142048 [details] t8.odt - same image stored twice as PNG (two identical), there is no longer PDF version
I don't know if this is related, but after closing all these documents and starting LibreOffice program again, I see crash notification http://crashreport.libreoffice.org/stats/crash_details/9123ed89-a773-4516-88ce-769ce0de7834
Similar problem mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=115005#c6 That bug should be fixed in LO6.0.4. I am going to test it.
Created attachment 142049 [details] still I can reproduce in 6.0.4 In case of undo functionality, I can reproduce this bug even in latest 6.0.4 version
Created attachment 142053 [details] I can partially reproduce in LibreOffice 5.4.6.2 also PDF is gone in LibreOffice 5.4.6.2 also, though here only one PNG remained (there is no duplicate PNG). Also, after deleting image (that inserted as PDF) and doing undo shows "Read error"
(In reply to opensuse.lietuviu.kalba from comment #0) > > It is not easy to reproduce, but most consistently I can reproduce by: > 1. Inserting PDF as image > 2. Save file > 3. Delete image. > 4. Save file. > 5. Insert another PNG image. > 6. Save file. > 7. Do undo until you see the first PDF image. > 8. Save file. > > LibreOffice installed via RPMs from LibreOffice site. > I use openSUSE Leap 42.3 Linux. I could follow the provided steps. But it is not clear to which saved file should contain both PDF and PNG and which saved file should contain identical PNG images.
After(In reply to Dieter Praas from comment #7) You should see both PDF and PNG after 2-nd step. You should see two identical PNG after 8-th step.
Indeed, seems 4-5th steps are not necesarry to reproduce.
Tried to reproduce it without steps 4 and 5. Result: File that is saved after step 2 contans PDF-File and PNG-File File that is savend after step 6 contains contains no picture File that is saved after step 8 contains PDF-File and PNG-File => I can't reproduce it with Version: 6.1.0.0.beta1 (x64) Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: en-US (de_DE); Calc: CL
I hope it will true in LibreOffice 6.1 for Linux also (I will test later beta version). Dieter indicated that problem already fixed in 6.1beta, – it would be nice to backport changes to 6.0.
(In reply to opensuse.lietuviu.kalba from comment #11) > I hope it will true in LibreOffice 6.1 for Linux also (I will test later > beta version). > > Dieter indicated that problem already fixed in 6.1beta, – > it would be nice to backport changes to 6.0. Acutally, this remains unconfirmed and without reliable STR. We don't know if it has been "fixed" in 6.1 or current 6.2/master as not clear it is a valid issue. Please test your result using parallel install [1] of 6.1 or master daily [2] for your OS, and refine your STR if possible so there is some chance of identifying what might (or might not) have corrected this. =-ref-= [1] https://wiki.documentfoundation.org/Installing_in_parallel [2] https://dev-builds.libreoffice.org/daily/
I can not reproduce this bug in LibreOffice version: 6.1.0.0.beta1 ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 threads: 4; OS:Linux 4.4; GUI: GL; VCL: gtk2; Locale: lt-LT (lt_LT.UTF-8); Calc: group Thus bug is fixed in LO 6.1, but we need to backport fix into LO 6.0
I also can not reproduce in Version: 6.2.0.0.alpha0+ Build ID: 90e4c55d01637178418c33ffe818263114a53374 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-06-12_00:10:12 Locale: lt-LT (lt_LT.UTF-8); Calc: group threaded
I still can reproduce in Version: 6.0.6.0.0+ Build ID: 4aaf958cdad2a19be49dbd5f9ca661753f8a94ab CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-0, Time: 2018-06-11_22:35:54 Locale: lt-LT (lt_LT.UTF-8); Calc: group
Since it is fixed in LO 6.1 and LO 6.2, I think we can close it as WORKSFORME.
LibreOffice 6.0 version is still supported version, right?
Back to NEEDINFO to OP, this has not been confirmed by any but OP. Please refine with Steps to Reproduce that others can follow consistently--otherwise this appears invalid.
The simplest way to reproduce bug in LibreOffice 6.0: 1. Open https://bugs.documentfoundation.org/attachment.cgi?id=142047 (it contains PDF as image) 2. Delete image. 3. Do undo. 4. Save file. 5. Open ODT document with archiver program (as ZIP archive) and you see two identical PNG images with same CRC (and size) but different names. One of these names was used for PDF image.
Thank you, now can confirm with STR comment 19 with 6.0.4.2 This is data loss of the original PDF stream when the replacement bitmap is deleted and restored and a new bitmap is created. It has been corrected for 6.1.0 beta1 or master/6.2.0 But, both the pdfium based image insert and image cache management have had work done. So this needs proper bibisect to identify where the "correction" occurs and decide if even possible to back port/fix 6.0
Hmm, through 2017-10-30 we got a "Read Error" on Undo:Delete Image, then at 2017-11-07 the Undo:Delete Image restores bitmap as a duplicated PNG, no PDF stream, when saved to ODF archive. https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d30522e46ca884e9bc74af21711d9537e8118859..a5af0fd9f27af42cf2e8571f659cdad6e606215b A tighter bibisect might confirm, but seems to be the fix of "Read Error" for bug 108748 gets supplemented with image cache handling for 6.1--its likely this would not/can not be back ported for a final 6.0 release, and this gets a WONTFIX =-ref-= http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a88795c1211c62277dc646e61c2ba8306febe37 https://gerrit.libreoffice.org/#/c/43906/
Reproducible for me under Ubuntu 16.04 x86-64 with LibreOffice 6.0.4 from Ubuntu PPA. Not reproducible with LO 6.1.0.0.beta2+ and master (6.2.0.0.alpha0+). Best regards. JBF
Perhaps related change in LO 6.1/master was described in https://bugs.documentfoundation.org/show_bug.cgi?id=115005 comment #18 : Serge Krot committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=79b2f1cb36ea4fec61b0620085313eb53fce9fa0 tdf#115005 Do not remove original vector images from slides
Horever Serge Krot committed a patch related to tdf#115005 (Do not remove original vector images from slides) and pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=070f3db51da48c70cde12050c18fb03de2192c0f&h=libreoffice-6-0 That patch should affect 6.0.4, but as you see, we still have dublicate PNG issue after using PNG vector images.
(In reply to opensuse.lietuviu.kalba from comment #24) > Horever Serge Krot committed a patch related to tdf#115005 > (Do not remove original vector images from slides) > and pushed to "libreoffice-6-0": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=070f3db51da48c70cde12050c18fb03de2192c0f&h=libreoffice-6-0 > That patch should affect 6.0.4, but as you see, we still have dublicate PNG > issue after using PNG vector images. No that does not appear to be related. The ipdf inserted PDF images do not pass through that code, they are never SVM. Rather the deletion/restore of the pdfium generated bitmap (PNG) breaks its linkage to its source PDF. That facet is fixed somewhere already in the filter implementation/image management for 6.1 and master/6.2,
Fixing commit reverse bibisected using repo bibisect-win32-6.1: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e4eb416c3ef81d098ed61caabd2077cbbb2418bc author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-04-01 14:47:13 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2018-04-10 08:34:13 +0200 remove swapping and link from GraphicObject and Graphic
As reverse bibisected, STR of comment 19 no longer error with > 6.1.0 Resolved => WFM