Bug Hunting Session
Bug 37678 - Export to raster formats (BMP, GIF, JPG, PBM, PNG, and PPM) links Resolution field with dimension fields (Width/Height)
Summary: Export to raster formats (BMP, GIF, JPG, PBM, PNG, and PPM) links Resolution ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 69888 (view as bug list)
Depends on:
Blocks: Draw-Images Graphics-Export
  Show dependency treegraph
 
Reported: 2011-05-27 17:23 UTC by Martin Norris
Modified: 2018-02-05 14:30 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
A drawing with a 1 inch line (8.20 KB, application/vnd.oasis.opendocument.graphics)
2011-05-27 17:23 UTC, Martin Norris
Details
The exported BMP (346 bytes, image/bmp)
2011-05-27 17:25 UTC, Martin Norris
Details
Screenshots of export dialog showing Resolution automatically changing Width. (80.50 KB, application/zip)
2013-11-15 22:52 UTC, Owen Genat (retired)
Details
BMP, GIF, JPG, PBM, PNG, and PPM exports at 96dpi and 300dpi from ODGs. (22.29 KB, application/zip)
2013-12-09 12:56 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Norris 2011-05-27 17:23:40 UTC
Created attachment 47239 [details]
A drawing with a 1 inch line

When exporting a page or selection as a bitmap, the resolution option in the "BMP Options" dialog is ignored.  It seems the resolution is capped at 97 dpi.

This is easy to reproduce - create a line 1 inch long.  Export the selection as a BMP.  Choose 600dpi.  The file created is a BMP 97 x 1.
Comment 1 Martin Norris 2011-05-27 17:25:20 UTC
Created attachment 47240 [details]
The exported BMP

Added attachment of exported 1 inch line
Comment 2 Martin Norris 2011-08-02 10:41:50 UTC
* WORKAROUND * (for Windows only, sorry!)

For anybody coming across the same problem from Google or where ever ...

1/ Print to a file using the MS XPS printer.  This creates an XPS file.

2/ Convert the xps to a bitmap (or jpg, png) using the open source tool xps2img
http://sourceforge.net/projects/xps2img/ 

Hope this helps
Comment 3 Regina Henschel 2011-11-23 14:12:54 UTC
It would be possible, but nobody has put it into the core yet. In the meantime you can use the extension "Enhanced export options for bitmap files" 
Currently still available from http://extensions.services.openoffice.org/de/project/EnhancedGraphicExportDialogs.
Comment 4 Björn Michaelsen 2011-12-23 12:06:35 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 13:59:59 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:01:08 UTC Comment hidden (obsolete)
Comment 7 Florian Reisinger 2012-08-14 14:05:52 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:07:54 UTC Comment hidden (obsolete)
Comment 9 sasha.libreoffice 2012-09-06 11:37:28 UTC
reproduced in 3.6.1 on Fedora 64 bit
in my case result was 125 dpi instead of 600
Comment 10 Julien Nabet 2013-10-15 20:11:18 UTC
I'm not image expert but with LO Debian testing package 4.1.1.2, I asked 600 dpi and had 600 dpi.
Anyone to confirm or to bring me back to reality?
Comment 11 Alexandr 2013-10-30 17:05:43 UTC
I'm not an image expert too, but I confirm the bug for libreoffice 4.1.2.3 in Windows 7 and libreoffice 4.1.0-5~bpo70+3 from debian backports. Changing in the “Resolution” field does not change the result of exporting. 

If  “Width” and “Height” are in length units (cm, inch, mm) they are changing automatically when “Resolution” is changing. But if they are in pixels? They are not changing with “Resolution”. I expect opposite behavior.

This is not a BMP only problem. Exporting to other formats is the same.

Dear Julien Nabet, can you write what exactly you did to reproduce the bug?
Comment 12 Regina Henschel 2013-10-30 17:42:17 UTC
In the meantime, the export works correctly, at least for .png format. But the dialog is a little bit tricky. You have to first set the desired DPI. Don't forget to set the correct unit. With changing the DPI the 'width' field changes too. You have to adjust the 'width' field to the correct value after you have set DPI.
Comment 13 Alexandr 2013-11-01 09:10:09 UTC
Yes, I know that I can set sizes of image manually. I think it would be more clear if length of 1inch line remain 1 inch when we change resolution.

Be careful exporting to png or gif due to bug 67477
Comment 14 Owen Genat (retired) 2013-11-15 22:52:33 UTC
Created attachment 89292 [details]
Screenshots of export dialog showing Resolution automatically changing Width.

I confirm behaviour as described in comment #11 and comment #13. Under Crunchbang 11 x86_64 running v4.1.3.2, regardless of resolution, export to BMP results in the attachment to comment #1. I have attached some screenshots of the export dialog showing the corresponding change in Width that results in the same effective resolution being output.

Attempting to export to GIF or PNG export resulted in a "Graphics filter not found" error.
Comment 15 tommy27 2013-12-09 06:29:50 UTC
*** Bug 69888 has been marked as a duplicate of this bug. ***
Comment 16 tommy27 2013-12-09 06:37:07 UTC
I set status to NEW because of previous comments.

@Owen
would you please come up with a better summary description of the bug?
as you said in the other report this is not limited to BMP but affects all raster formats.
Comment 17 Owen Genat (retired) 2013-12-09 12:56:13 UTC
Created attachment 90509 [details]
BMP, GIF, JPG, PBM, PNG, and PPM exports at 96dpi and 300dpi from ODGs.

Here is a bit more information on this problem. Of the raster file types available via File > Export only BMP, GIF, JPG, PBM, PNG, and PPM offer the Options dialog where dimension and resolution can be adjusted. As Alexandr indicates in comment #11 this problem is not restricted to BMP. The workaround suggested by Regina in comment #12 (set the resolution and then subsequently adjust the dimension) works for shapes (attached "square" ODG+rasters) but is not effective for lines: the resultant files produced are basically identical e.g., the attached "line" graphics are produced from the one inch line ODG provided in attachment 47239 [details]. 

To further complicate matters, as I indicated in comment #14 there currently appears to be a separate issue with the GIF and PNG filters not handling exporting of a line object under v4.1.3.2. The attached files indicate the results of exporting a one inch line and 1x1 inch square to the indicated raster formats under Ubuntu 10.04 x86_64 using v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a.
Comment 18 Owen Genat (retired) 2013-12-09 13:08:13 UTC
(In reply to comment #16)
> @Owen would you please come up with a better summary description of the bug?

I will quote my comment from bug 69888 here for clarity:

> At some point I would hope the Resolution field is decoupled from the dimension 
> fields i.e., instead of single Size section a Dimension and Resolution section 
> are provided, each with value and unit selections.

Summary accordingly altered to "Export to raster formats (BMP, GIF, JPG, PBM, PNG, and PPM) links Resolution field with dimension fields (Width/Height)". These attributes are generally considered independently variable (and expected to behave as such unless explicitly linked) when creating graphics. 

Platform changed from Windows to All as a result of comment #9, comment #11, comment #14, and comment #17.
Comment 19 Alexandr 2013-12-11 17:16:27 UTC
> The workaround suggested by Regina in comment #12 ... is not effective 
> for lines: the resultant files produced are basically identical

The problem is with horizontal or vertical lines with zero width, i. e. if one of the dimensions is zero. If the line has a nonzero width or placed with an angle, the workaround works.
Comment 20 Buovjaga 2014-11-15 13:58:31 UTC
*** Bug 85761 has been marked as a duplicate of this bug. ***
Comment 21 QA Administrators 2015-12-20 16:18:28 UTC Comment hidden (obsolete)
Comment 22 Gary 2015-12-23 14:26:54 UTC
LibreOffice v5.0.4.2
OS: Win7sp1

The bug is still present in 5.0.4.2

It is necessary to examine the image attributes in the exported image file to observe the problem.

In the export image dialog the user can set the image size (width and height) and the resolution (pixels/inch or cm or meters). (The default resolution is 96 pixels/inch in my installation.)

In the above dialog if I set the resolution to something other than the default of 96 pix/in, such as 300 pix/in, this new value is not applied to the exported file. The exported file image resolution remains at 96 pix/in.
Comment 23 QA Administrators 2017-01-03 19:55:38 UTC Comment hidden (obsolete)
Comment 24 Michael Bauer 2017-01-03 22:53:46 UTC
Persists
Comment 25 Martin Norris 2017-01-04 10:43:56 UTC
Hi,

Since I filed the original report, I thought I should comment!

Yes the behavior persists

OS Win 7 

LibreOffice "Versão: 5.2.3.3 (x64)
ID de compilação: d54a8868f08a7b39642414cf2c8ef2f228f780cf
Threads da CPU:4; Versão do SO: Windows 6.1; Realizador da interface: padrão; 
Local: en-GB (pt_BR); Calc: group" {from help}

Exported BMP file is 97 x 1 {97dpi}

I did not try any of the workarounds suggested since I imagine you want to check the original bug

Hope this helps

Martin
Comment 26 Heiko Tietze 2018-02-05 14:29:52 UTC
Closing this ticket as the original issue was fixed quite quickly. The UI problem remains and is tracked in bug 115464.