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.
Created attachment 47240 [details] The exported BMP Added attachment of exported 1 inch line
* 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
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.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
reproduced in 3.6.1 on Fedora 64 bit in my case result was 125 dpi instead of 600
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?
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?
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.
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
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.
*** Bug 69888 has been marked as a duplicate of this bug. ***
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.
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.
(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.
> 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.
*** Bug 85761 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Persists
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
Closing this ticket as the original issue was fixed quite quickly. The UI problem remains and is tracked in bug 115464.