The GIF images are not rendered in the attached file Embedded_GIF_created_by_LibreOffice3_3_3.doc. This is a regression because they rendered correctly in LibreOffice v3.3.3, which created the document. The same file renders correctly in Jarte v4.4 (http://www.jarte.com/download.html) when Microsoft's Office File Converter Pack is installed.
Created attachment 50030 [details] Rendering failure
Created attachment 50031 [details] Correct rendering The attached file Embedded_bitmap_created_by_Jarte.doc renders correctly in LibreOffice v3.4.2 and v3.3.3 and in Jarte v4.4. It shows how the other attachment should render.
My results with "LibreOffice 3.4.2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:203)]": I see small "AA" logo pictures in both documents, in "Embedded_GIF_created_by_LibreOffice3_3_3" they are shown smaller than in "Embedded_bitmap_created_by_Jarte", control points (after click) some mm outside the logo. "Embedded_bitmap_created_by_Jarte" has filename extension ".doc", but it is a .RTF Saving "Embedded_bitmap_created_by_Jarte.doc" with LibO 3.4.2 as "Embedded_bitmap_created_by_Jarte_NEW342.doc" (WORD97 XP), closing and reopening it shows little AA logos perfectly in MS WORD VIEWER and LibO 3.3.3 Portable, but too small in LibO 3.4.2. Saving "Embedded_bitmap_created_by_Jarte.doc" with LibO 3.3.3 Portable as "Embedded_bitmap_created_by_Jarte_333.doc" (WORD97 XP), closing and reopening it shows little AA logos perfectly in MS WORD VIEWER and LibO 3.3.3 Portable, but too small in LibO 3.4.2. So the problem seems to be that LibO 3.4.2 only shows logos correctly in .RTF, but not in .DOC? Although history of document creation is obscure, it seems to be a VIEWING bug, because MS WORD Viewer shows logos in perfect way. I can't tell whether the logo really is a .GIF, when I save the documents as .odt, I find a .wmf in the zipped file system. Sill a problem with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" My Conclusion: -------------- Gif pictures in particular .doc created from .rtf shown wrong, picture size correct, but contents shrunken and surrounded by white margin. See Attached Screenshots! @reporter: May I ask you to read hints on <http://wiki.documentfoundation.org/BugReport> carefully? Then please: 1. Attach original .GIF, try to confirm my Conclusion 2. If you (may be additionally) see other problems, please file a new bug report and - Write a meaningful Summary (what the hack is the failure?) - Attach screenshots with comments (you can add information using LibO DRAW and then attach your screenshot with comments as PDF) if necessary - Attach the source document (or is "Embedded_bitmap_created_by_Jarte.doc" the source document? - add information -- Why did you attach those 2 documents? -- Did you want to report a FILEOPEN problem (file is correct, but shown wrongly) or FILESAVE problem (document damaged after save) -- what exactly is unexpected (you see nothing? Placeholder? too small, too big? "GIF images are not rendered ..." is a too rare description. -- and why do you believe it's unexpected -- concerning your PC (especially: video card) -- concerning your OS (exact version / localization) -- concerning your LibO version and localization (UI language) –- Libo settings that might be related to your problems (video hardware acceleration ...) -- how you launch LibO and how you opened the sample document –- If you can contribute an OOo Issue that might be useful -- everything else crossing your mind after you read a.m. URL Can you please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide? Thank you! @Cédric: Please feel free to reassign if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Created attachment 50059 [details] Screenshots, see Comment 3
Created attachment 50071 [details] Embedded_GIF_created_by_LibreOffice3.3.3--rendered_by_LibreOffice3.4.2 This screen capture shows the rendering problem with shrunken GIF images.
Created attachment 50072 [details] Embedded_GIF_created_by_LibreOffice3.3.3--rendered_by_LibreOffice3.3.3 Screen capture showing correct rendering.
@M8R-19jnla@binkmail.com: That's all known, documented, we do not need your screenshosts with completelyx misleading title. We need the original picture.
Thank you Rainer for your help. I added some screen capture PNG images to clarify the problem. I did not realize that the GIF image was being rendered by LibreOffice3.4.2 shrunken. It was so small that I mistakenly thought it was a place holder icon. Thanks again to Rainer for diagnosing the problem more exactly. The attached file Embedded_GIF_created_by_LibreOffice3_3_3.doc was created by LibreOffice3.3.3 from a .doc file created by Microsoft's Office 2007 Compatibility Pack, not a .rtf file as Rainer guessed. Therefore, I corrected the bug summary. Note that Embedded_bitmap_created_by_Jarte.doc was created by Jarte from Embedded_GIF_created_by_LibreOffice3_3_3.doc. I included Embedded_bitmap_created_by_Jarte.doc to as an example of what the GIF image should look like, and I did not realize it was in .rtf format. Now that I attached screen captures for the rendering of Embedded_GIF_created_by_LibreOffice3_3_3.doc, you could ignore Embedded_bitmap_created_by_Jarte.doc. The original GIF image can be found at https://www.aa.com/content/images/carrierLogos/AAL.gif Today I tested printing of Embedded_GIF_created_by_LibreOffice3_3_3.doc. Both LibreOffice versions printed just like they rendered on the screen, as seen by my screen capture PNGs. Thus, it seems to be both a VIEWING and PRINTING bug. This is the first bug that I reported to LibreOffice. I am a professional software developer for embedded microcontroller code, but I am unfamiliar with LibreOffice development. The best I know how to do is provide an example file and screen captures to reproduce the correct result and the bug.
I'm afraid a very particular chain of circumstances causes that picture shrinking. Although I do not believe that it can bring game-changing new knowledge I would have liked to do ma own test with original .gif. Unfortunately currently it's completely impossible for me to create my own .rtf because of "Bug 39960 - Pictures lost when FILESAVE document as RTF". So now we will have to wait for Cédric's results. @M8R-19jnla@binkmail.com: May be you can try to confirm my problem from Bug 39960?
The file Embedded_GIF_created_by_LibreOffice3_3_3.doc renders correctly with LibreOffice3.3.4.
LibreOffice v3.4.3 has the same behavior as LibreOffice v3.4.2.
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Created attachment 51280 [details] Archive with the sample text where pictures are rendered right in rtf but wrong in doc I also have problems with pictures rendering in LO v. 3.4.2. I attached the archive which explains the problem. The sample_tex.tex file is the source text file. I've converted it into rtf by means of latex2rtf. The formulas were converted into png images. All png images are represented in the archive. After that I opened the sample_tex.rtf in LO and saved the file in doc. When I reopened sample_tex.doc file the png formulas are rendered wrong (small size). OS: OpenSUSE 64 bit LibreOffice is installed from: http://download.opensuse.org/repositories/LibreOffice:/Stable/openSUSE_11.4/ LO version: 3.4.2
Found bug 39358 : https://bugs.freedesktop.org/show_bug.cgi?id=39358 is a duplicate of this bug...
*** Bug 39358 has been marked as a duplicate of this bug. ***
Thank you rainer!
I think nobody has really understood the gravity of this bug!!! (not sure because english is not my natural language...) This is is not only a rendering bug : when you save your modifications you save the bad images in place of the godod ones. So, if you edit the document with LO 3.4.2/3.4.3 and save it, it will corrupt your images. Even opened with Word Viewer they stay corrupted. Edit and save a document many times, and images will be shrunk more and more... Now that LO 3.4.3 is tagged 'Safe for production use by most users and enterprises', I think it is a serious bug. In production I have seen my documents corrupted (logos) ... Thanks...
OS due to Comment 13 @dleger@free.fr Currently it seems only few particular pictures are affected? My experience with "Lavado, planchado y secado.doc" from Bug 39358: I saved a version saved 3 times with LibO3.4.3 (so that the pictures were terribly distorted) after reopen as .odt. I checked the embedded pictures, they are ok, and when I closed / reopened .odt, the pictures looked normal. So it's not a real dataloss, but, of course, annoying.
Created attachment 51648 [details] Model with problematic logo my experience : Open Charte.ott and save as .doc file. Open the .doc file and edit/save it 3 times. The logo is distorded. Save the file as .odt : the logo is better but not totally repaired!!! (it is smaller than original) I think this bug is particularly vicious/insidious since you don't see it happening. So when you see the bug, you have already corrupted many documents. I know it is better to work with .odt files. But often you receive a .doc file, and basic user will work with .doc (he won't think to convert). TIA
Created attachment 51791 [details] Peugeot.jpg More investigations for this bug : Fistly .jpg embedded images are affected too. Secondly it only affect images where anchor is selected "as caracter" Look at Peugeot.jpg (Anchor options)
Created attachment 51879 [details] Multiple logos Tested with many images found on the web : .jpg .JPG .jpeg .png .gif .tif .bmp : all images format are affected I confirm the only criteria for this bug is images where anchor is selected "as caracter" Original (correct) is : logos.odt Bad result is : logos.doc Please note that logos.odt was simply saved as a .doc file. Result file is distinctly incorrect. If you work (edit/save) with .doc file images will be more distorded.
It seems that Noel has fixed this bug on master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=991aa4fff785612bad7281f4948f5771bf8d215a So, reassigned and marked as FIXED.
(In reply to comment #22) > It seems that Noel has fixed this bug on master: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=991aa4fff785612bad7281f4948f5771bf8d215a > So, reassigned and marked as FIXED. huh? have you tested that or just guessing, I'd say guessing as the description (from what I have read) is about something completely different. Don't mark things as fixed when not tested please
(In reply to comment #23) > (In reply to comment #22) > > It seems that Noel has fixed this bug on master: > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=991aa4fff785612bad7281f4948f5771bf8d215a > > So, reassigned and marked as FIXED. > > huh? have you tested that or just guessing, I'd say guessing as the description > (from what I have read) is about something completely different. Don't mark > things as fixed when not tested please hehe, I was a bit hasty, I pasted the commit but it appears that I didn't copy it properly and got a commit from my clipboard ( for a completely different fix ) the commit mentioned in comment #22 looks indeed like a likely candidate as a fix. Really would appreciate confirmation if indeed this does fix this
(In reply to comment #24) > the commit mentioned in comment #22 looks indeed like a likely candidate as a > fix. Really would appreciate confirmation if indeed this does fix this Surely I have tested before marking as fixed! :-) The import of images works fine with this commit, thanks for it, Noel.
(In reply to comment #25) > Surely I have tested before marking as fixed! :-) The import of images works > fine with this commit, thanks for it, Noel. thanks for re-testing, appreciate that ( sorry for the noise :-) )
Gentlemen, please tell me, in what release of LO this bug is fixed? I mean, where must I download LO to work with doc-files in proper way?
Re-marking FIXED then; Aleksey - I've pushed Noel's fix to the libreoffice-3-4 branch, it'll be in LibreOffice 3.4.5 as/when that ships (perhaps sooner rather than later - the schedule may be adjusted). The fix will also be in 3.5.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Well... it seems it's fixed only for the frameless pictures. When a picture has a border, the problem is still there 'see attachment). By the way, a 1/2pt border looks much thicker on LO than on MSO but this might need another bug report.
Created attachment 55893 [details] Doc with a simple framed picture
Regression does appear in oldest version of bibisect-3.5.tar.lzma and must be older.
I opened attachment 55893 [details] in LO 3.5.1 release on Win7 x64 SP1, and it looks correct to me (no shrunken content). Is this bug fixed in LO 3.5.1 release or does it manifest on a different platform?
(In reply to comment #31) Indeed some observations are similar to original report, but I am pretty sure that this new one has different roots than the problem from original report, what was a regression, while Olivier's problem is inherited from OOo I created a new "Bug 47954 - FILEOPEN: VIEWING of picture anchored as character with unexpected distance to border" for that problem and close this one again, because see evidence that the problem from Olivier's comment is different @Olivier Berten <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>
Comment on attachment 55893 [details] Doc with a simple framed picture "Doc with a simple framed picture" has nothing to do with original report.