Description: It is possible to export a document as jpg or png image. It is also possible to change the dpi setting. The default setting is the dpi value of the display, in my case 96 dpi. Changing the setting to 150 dpi should result in a file with more pixels, however that does not happen. It seems display value is always used. Steps to Reproduce: 1. choose export as.. to export a document as png or jpg 2. First use the default dpi setting. 3. Do the same thing again, but with a different dpi setting 4. Compare both resulting images. Actual Results: Both resulting images have the same size. Expected Results: The image with the higher dpi setting should be bigger with more pixels. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info:
I cannot reproduce the problem. Perhaps you have forgotten to adjust the width and height after you have changed dpi?
With 'size' I mean the size in kB. The size of the document in cm is of no importance, using a higher dpi setting should result in more pixels, and thus in a bigger file (more kB).
The export dialog has fields for width and height. If you change the dpi in that dialog the width and height are automatically adapted, so that the number of pixels is kept. To get a different number of pixels, you have to set the width/height manually after you have changed the dpi. There is an ongoing discussion for a better dialog, see bug 115464.
I see what you mean.. This behaviour is quite ludicrous I'm afraid. The dpi setting of my display has absolutely nothing to do with the dpi setting of the image I would like to have. I have a document / page with a certain size in cm. Unless I explicitly want to change that size, it should remain as it is. What's even worse, all internal calculations are not done on the original document, but instead on recalculated versions of that document. Example: set the dpi setting to 150, and then change it back to 96. The resulting image size in cm is smaller then the original document I started with. All calculations should be made based on the original document! Otherwise the quality of the resulting image will suffer. This whole thing is yet another indication that the graphics engine of Libreoffice needs a very good overhaul.
(In reply to Dirk Munk from comment #4) > I see what you mean.. > > This behaviour is quite ludicrous I'm afraid. >..> > This whole thing is yet another indication that the graphics engine of > Libreoffice needs a very good overhaul. Not the engine is bad but "only" the dialog, therefor bug 115464. This bug report should actually be classified as "wordforme", but I set it to "duplicate" so it appears as a link in the other bug report. *** This bug has been marked as a duplicate of bug 115464 ***
There's a bit more to it than just that. It all starts out with .odt document A. When we parameters for the .png or .jpg file, the image is calculated as soon as we set one parameter, it results in a intermediate result B. Change a parameter, and a new version B will be recalculated from the previous version of B. So the original document is not used for the calculations, but instead the intermediate results. That will not result in an optimal result! For every new version of B, the input should be the original .odt file A. In fact, there should be a OK button before LibreOffice starts calculating the graphical file. Now it calculates while you type, why?