Download it now!
Bug 115287 - Editing: after many, many, many years, Writer is still not capable of inserting an image properly
Summary: Editing: after many, many, many years, Writer is still not capable of inserti...
Status: RESOLVED DUPLICATE of bug 52598
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Image-DPI
  Show dependency treegraph
 
Reported: 2018-01-28 23:46 UTC by Dirk Munk
Modified: 2018-03-01 14:50 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
jpeg headers with highlighted image size and dpi information (43.98 KB, application/pdf)
2018-01-29 00:31 UTC, Dirk Munk
Details
TIFF 6.0 specification (302.43 KB, application/pdf)
2018-01-29 01:25 UTC, Dirk Munk
Details
TIFF specification supplement 1 (39.06 KB, application/pdf)
2018-01-29 01:28 UTC, Dirk Munk
Details
TIFF specification supplement 2 (304.28 KB, application/pdf)
2018-01-29 01:28 UTC, Dirk Munk
Details
test image (82.05 KB, image/jpeg)
2018-01-29 08:40 UTC, Dirk Munk
Details
File header info of Test Image (70.53 KB, application/pdf)
2018-01-29 14:19 UTC, Dirk Munk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Munk 2018-01-28 23:46:24 UTC
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
Comment 1 Dirk Munk 2018-01-29 00:31:52 UTC
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.
Comment 2 Dirk Munk 2018-01-29 01:25:58 UTC
Created attachment 139416 [details]
TIFF 6.0 specification

The current TIFF header specification
Comment 3 Dirk Munk 2018-01-29 01:28:04 UTC
Created attachment 139417 [details]
TIFF specification supplement 1
Comment 4 Dirk Munk 2018-01-29 01:28:58 UTC
Created attachment 139418 [details]
TIFF specification supplement 2
Comment 5 Dirk Munk 2018-01-29 08:40:18 UTC
Created attachment 139422 [details]
test image

Just insert this imaga in a Writer document, and see what happens.
Comment 6 Telesto 2018-01-29 09:03:32 UTC
This is a dupe of bug 52598, right?
Comment 7 Dirk Munk 2018-01-29 09:42:17 UTC Comment hidden (no-value)
Comment 8 Telesto 2018-01-29 10:59:11 UTC
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
Comment 9 Dirk Munk 2018-01-29 11:54:57 UTC
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.
Comment 10 Regina Henschel 2018-01-29 12:11:20 UTC
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.
Comment 11 Dirk Munk 2018-01-29 12:29:23 UTC
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!!
Comment 12 Dirk Munk 2018-01-29 12:35:24 UTC
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!
Comment 13 Dirk Munk 2018-01-29 14:19:41 UTC
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.
Comment 14 Dirk Munk 2018-02-05 12:56:43 UTC
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?
Comment 15 Telesto 2018-02-05 21:02:17 UTC
(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.
Comment 16 Buovjaga 2018-03-01 14:50:09 UTC
(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 ***