Description: In the headers of an image file is information about the size of the image (in pixels), and the dpi setting for that image. With that information, it is very simple to calculate the desired print size for the image (in inch/cm). How difficult can it be. Very simple, very basic. And yet, after many, many years, Writer is still not capable of extracting the dpi information from the headers, and calculating the proper image size in inch/cm. Instead it uses the dpi setting of the computer display, why I have no idea. The result is that images appear in the wrong size in the document. Strangely enough Writer is capable of scaling the image and making all kind of graphic calculations, but I don't want that to happen!!!!!!!!!!!!! I just want Writer to use the image file as is, how difficult can it be. This has been reported many times, and yet no one in developer community has taken the trouble to fix this very simple problem. I love LibreOffice, but if the developers don't take the time to resolve very simple but very annoying bugs, then they should think about their priorities. Steps to Reproduce: 1.Create an image with (for instance) Photoshop Elements, make sure it has a high dpi setting (300 dpi for instance). 2.Insert the image in a Writer document, and see that the image gets far to big. 3.Try desperately to correct it, and give up. Actual Results: Image is inserted with the wrong size Expected Results: Image should be inserted as is, with the proper dpi setting as in the headers of the image. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 139415 [details] jpeg headers with highlighted image size and dpi information These are the headers of a jpeg file with a resolution of 300 dpi. I have highlighted the size of the picture and the resolution. Please, oh please, make Writer understand the resolution info.
Created attachment 139416 [details] TIFF 6.0 specification The current TIFF header specification
Created attachment 139417 [details] TIFF specification supplement 1
Created attachment 139418 [details] TIFF specification supplement 2
Created attachment 139422 [details] test image Just insert this imaga in a Writer document, and see what happens.
This is a dupe of bug 52598, right?
Yes indeed it is, and a duplicate of many other bugs. But whatever information I add to the original bug report, no one gives a s***t. So I just enter a new one, hoping and praying that finally some one will pick up this simple problem and fix it. It is the only way to get some attention.
Sadly, there are only limited resource - DEV's - available. The can - more or less - pick whatever the want. Any coding skills? Everyone can contribute ;-) It might or not - my code reading is pretty bad - be related to this: https://opengrok.libreoffice.org/xref/core/vcl/source/filter/jpeg/JpegReader.cxx#220 or https://opengrok.libreoffice.org/xref/core/vcl/source/filter/graphicfilter2.cxx#331
I know about the limited resources, but inserting an image is base functionality, so such a bug should get high priority. A user should be able to rely on Writer that it will properly insert an image. I spend a lot of time creating and improving images with Photoshop, and once they are ready I should be able to insert them into a Writer document without problems. To make it even worse, this problem is at least 5 years old, or perhaps it existed from the very beginning. I was a COBOL programmer once, and I'm not familiar with C or C++. However, for a programmer it is always possible to remotely understand code of a language he doesn't know. I think the problem may be in the first piece of code you send me, starting at >> if (mbSetLogSize) << . In the TIFF headers there are three possible types of entry for the density, 1 = no density information, 2 = density in dots per inch (dpi), and 3 = density in dots per centimetre (dpc). I get the impression that the value nUnit is this setting, but that the size calculation is only done for type 1 (no density specified). Type 3 is completely ignored. I'm sure it is rarely used, but that doesn't matter. It exists, and it should be handled properly.
Bug 52598 is about jpeg-images; so no need for another bug report. I do not see wrong dpi for png-images. Could you please provide image examples for the tiff-cases do you mentioned? The image in tiff-format, which I have generated, shows correct dpi in LibreOffice.
It should not be necessary to file another bug report, but unfortunately no one is paying any attention to bug 52598. My last attachment (test image) is a jpeg file example that will not be inserted properly. TIFF headers are also present in JPEG files!!
You're absolutely right, PNG files are handled correctly. All these type of files use the same TIFF headers! As an ex-programmer, I would say there should be ONE subroutine to handle these headers!
Created attachment 139436 [details] File header info of Test Image I have made file header information of the jpg version of the test image, and of the png version. As you can see, the TIFF headers in both have the same structure, and are almost identical.
I tried some other formats as well, like TIFF and PSD. The same result, the picture is inserted with the wrong format. So far, PNG is the only image type that is inserted properly. I would call this a major problem, not being able to properly insert an image. Can some one please confirm the problem, and elevate it to a major problem since it seems to concern many image formats?
(In reply to Dirk Munk from comment #14) > I tried some other formats as well, like TIFF and PSD. The same result, the > picture is inserted with the wrong format. > > So far, PNG is the only image type that is inserted properly. > > I would call this a major problem, not being able to properly insert an > image. > > Can some one please confirm the problem, and elevate it to a major problem > since it seems to concern many image formats? Only for the record: PNG import is fine, export is broken too. See bug 109323.
(In reply to Dirk Munk from comment #11) > It should not be necessary to file another bug report, but unfortunately no > one is paying any attention to bug 52598. Still no reason to duplicate it. Closing. *** This bug has been marked as a duplicate of bug 52598 ***