LibreOffice 5.0.4.2 - Draw If Image is exported to TIFF the resulting image has resolution x: 0,017 pixel/inch and y: 0,167 pixel/inch. Resolution should be 96 pixel/inch for both, x and y. Also, the amount of pixels of the image drops to one third, e.g. from 1000 to 350. ----- In LibreOffice 4.3 - Draw it has always been correct.
Hello, Thank you for reporting the bug. Please add the following information as this makes it easier for us to verify the bug: 1. Clearer step by step way to reproduce the problem: like 1. do this 2. do that etc... 2. A sample image file to start testing with as I could not reproduce it I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested info is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 123704 [details] fabric pattern for settee and armchairs Do export the attached draw-file as TIFF and open the imagefile in GIMP, par example and check the x/y-resolution and amount of x/y-pixels compared to an export to PNG of the same draw-file. If I do export to PNG then the background of the pattern is missing. So I cannot use PNG. JPEG makes the quality worse. It's a pity. Remark: I do need the export to TIFF for splitting the whole image into 6 sheets of A4 size for printing. It is impossible to print this draw-file directly from LibreOffice.
Confirmed with ubuntu 14.04 x64. Output to tiff is 2048*223, while output to png is 5557*605. > If I do export to PNG then the background of the pattern is missing. So I cannot use PNG. You can fix that by turning 'save transparency' in the png options off.
Confirm it on: Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) OS: Windows 7 Enterprise If image saved using tiff it would be hard to read.
If I export a draw-file to PNG, BMP or JPEG then a window pops up "PNG options" where dimension, resolution, compression, modus an so on can be changed. There is no window "TIFF option" when export to TIFF is done. LibreOffice does this quietly and the result is weird, i.e. useless. (In reply to Usama from comment #4) > If image saved using tiff it would be hard to read. Do check the resolution: It is x: 0,017 pixel/inch and y: 0,167 pixel/inch.
** 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.2.7 or 5.3.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-20170522
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still an issue in 6.3.3.2 on Windows 7 64 bit. There is no "TIFF Options" windows when exporting in TIFF format from Draw, so it's impossible to set Width/Height/Resolution of the exported image. Moreover, in the exported TIFF image file the x and y resolution parameters are both set to very weird values.
LO 41max oldest- resolution 0,0172414 × 0,166667 ppi. Is it really regression?
The bug reporter wrote that the tiff files exported by LibreOffice Draw 4.3 were correct.
Bibisect request is bogus. The resolution is always 2048x223 or 2048x302 pixels when tested with older versions, Linux bibisect repos 43all (oldest, 3.5.0), 41max, 43max, 44max, 50max.
(In reply to Andrea Giudiceandrea from comment #9) > There is no "TIFF Options" windows when exporting in TIFF format from Draw, > so it's impossible to set Width/Height/Resolution of the exported image. Workaround: 1. Export to PNG/JPG (setting values). 2. Open in image-editing program that can save as TIFF.
(In reply to sdc.blanco from comment #13) > (In reply to Andrea Giudiceandrea from comment #9) > > There is no "TIFF Options" windows when exporting in TIFF format from Draw, > > so it's impossible to set Width/Height/Resolution of the exported image. > Workaround: 1. Export to PNG/JPG (setting values). 2. Open in image-editing > program that can save as TIFF. Which negates the entire point of having a TIFF export option at all in LO draw. This bug is similar to mine which no one's ever looked at https://bugs.documentfoundation.org/show_bug.cgi?id=139161
(In reply to sdc.blanco from comment #13) > Workaround: 1. Export to PNG/JPG (setting values). 2. Open in image-editing > program that can save as TIFF. Sorry, this in no workaround, because with PNG the background of the pattern is missing and JPG makes the the quality worse. (see Comment #2 2016-03-18 21:17:55 UTC) Six years later, there is still no "TIFF Options" window when exporting your work from Draw into TIFF format. Still, the amount of pixels of the image drops to one third, e.g. from 1000 to 350. Version: 7.2.3.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.utf8); UI: de-DE Calc: threaded
I submitted a patch to just indicate that we use 96 DPI when exporting in TIFF. https://gerrit.libreoffice.org/c/core/+/135631 As I indicated in the comment: "Next step would be to use the dialog box for compressing options (like for png or jpg). But for this I think we should take benefit of external lib "libtiff" since we now use it now for import." but this part would take more time.
About "dialog box for compressing options", there's already tdf#92944 about this.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/988285410f8883ad49f32c4b804c4f5bd14569d0 tdf#98743: TIFF export uses 96dpi by default It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Not exactly sure what the test is supposed to be here, but in using this: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 988285410f8883ad49f32c4b804c4f5bd14569d0 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL The original bug attachment, exported as TIFF, was 2048x233
Probably a distraction in regard to the current bug, but saving out the attachment in 7.5 LO produced a 477k file, while exporting using paint.net using default TIFF settings (auto-detect depth) the file size was 277k. Same dimensions.
xordevoreaux: LO Debian package 7.3.4.1 (so without the patch) exports a file of 453302 bytes with these info (from tiffdump): Magic: 0x4d4d <big-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 8 (0x8) next 0 (0) SubFileType (254) LONG (4) 1<2> ImageWidth (256) LONG (4) 1<2048> ImageLength (257) LONG (4) 1<223> BitsPerSample (258) SHORT (3) 1<8> Compression (259) SHORT (3) 1<5> Photometric (262) SHORT (3) 1<2> StripOffsets (273) LONG (4) 1<198> SamplesPerPixel (277) SHORT (3) 1<3> RowsPerStrip (278) LONG (4) 1<223> StripByteCounts (279) LONG (4) 1<453104> XResolution (282) RATIONAL (5) 1<0.0172414> YResolution (283) RATIONAL (5) 1<0.166667> PlanarConfig (284) SHORT (3) 1<1> ResolutionUnit (296) SHORT (3) 1<2> with master sources updated today, it exports a file of 453302 bytes too. Magic: 0x4d4d <big-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 8 (0x8) next 0 (0) SubFileType (254) LONG (4) 1<2> ImageWidth (256) LONG (4) 1<2048> ImageLength (257) LONG (4) 1<223> BitsPerSample (258) SHORT (3) 1<8> Compression (259) SHORT (3) 1<5> Photometric (262) SHORT (3) 1<2> StripOffsets (273) LONG (4) 1<198> SamplesPerPixel (277) SHORT (3) 1<3> RowsPerStrip (278) LONG (4) 1<223> StripByteCounts (279) LONG (4) 1<453104> XResolution (282) RATIONAL (5) 1<96> YResolution (283) RATIONAL (5) 1<96> PlanarConfig (284) SHORT (3) 1<1> ResolutionUnit (296) SHORT (3) 1<2> So imageWidthxImageLength is 2048x223 in both cases. The only thing changed here is XResolution and YResolution as expected. About the size of the file, you can attach here since it depends on the options used by Paint but perhaps it would need a brand new bugtracker.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2b7979d781b9e46161dcdfcab0e258af5e0b12b6 Revert "tdf#98743: TIFF export uses 96dpi by default" It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I reverted the patch since it doesn't work with the file attached. It's not normal that the nb of pixels drops.
Created attachment 180750 [details] original bug report's file, exported as a tif from paint.net Paint.net uses three parameters with TIF exports: a dithering level (1 to 8) bit depth (1, 4, 8, 24, 32) and a quantization algorithm dependent on selected bit depth (Median Cut, Octree) With me using paint.net's auto-detect setting, paint.net selected Octree for the algorithm and a dithering level of 7 when re-saving the original bug reporter's attachment as a TIF file. Paint.net forces use of the octree quantization algorithm for bit depths 24 and 32, and the user is given the choice between octree and median cut for depths 1, 4, and 8, but does not report on the UI what the actual bit depth was if set to auto-detect (but because Octree was defaulted, the auto-detected bit depth had to be either 24 or 32). Wild guess here, perhaps the engine you're using for the TIF export is not reporting everything it's implementing during the export process and is locked to a particular export format, or is using an optimization algorithm other than the one paint.net is using (which wouldn't of itself be a bug, just a different approaching to performing the export). I did not see any visual difference between the original and paint.net's export, so I'm not sure what information got lost between the original's 417K and paint.net's 277K export.
The issue still occurs using LibreOffice Draw 24.2.4.2 on Windows 10 64-bit.