Created attachment 124315 [details] test file Steps: open file crop image compress image (cubic, 200 dpi) image dispappear
This seems to have begun at the below commit. Adding Cc: to Chris Sherlock; Could you possibly take a look at this one? Thanks 088891b7b6c325ed3dbca34db651af30c3b6529a is the first bad commit commit 088891b7b6c325ed3dbca34db651af30c3b6529a Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Feb 18 00:01:21 2016 -0800 source f8355221ae62b89a706f2d04b63eda658f3ccfa5 author Chris Sherlock <chris.sherlock79@gmail.com> 2016-02-13 05:08:01 (GMT) committer Tomaž Vajngerl <quikee@gmail.com> 2016-02-14 20:51:08 (GMT) commit f8355221ae62b89a706f2d04b63eda658f3ccfa5 (patch) tree 6a01919926776dc5c36ffb825dc69b46ba66fbac parent 19fb09dce67d29d480ff39c538209b887f661dc9 (diff) tdf#85761 vcl: JPEG export does not save PPI values correctly
Repro. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 334599030e7b45153107a3075f9049a7463aac80 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 22nd 2016
Created attachment 125076 [details] Valgrind part On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. I attached a part of Valgrind (the rest of is Java stuff), perhaps it may help.
This is still reproducible in Version: 5.3.0.0.alpha0+ Build ID: 33a2e47c907f7e2c1995b4a1e910dec94c3cedb4 CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; Locale: ca-ES (ca_ES.UTF-8); Calc: group
*** Bug 99265 has been marked as a duplicate of this bug. ***
Is this fixed in LO 5.3.x branch ?
(In reply to Gérald Maruccia from comment #6) > Is this fixed in LO 5.3.x branch ? No, still repro Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 1bdef25291dea612305fa2cb8dd806466aa97773 CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 4th 2016
*** Bug 109227 has been marked as a duplicate of this bug. ***
I'm still seeing this regression bug, now more than 18 months old: Version: 5.4.0.3 (x64) Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.29; UI render: default; Locale: en-US (en_US); Calc: group This basically means LibreOffice can not reliably compress files with images.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed that if I try compress first, then crop and compress, the image doesn't disappear. However, I noticed too that if I compress a first time and I try a second time, the value didn't change (still 96dpi instead of 200 dpi)
That bug obstinacy becomes ridiculously painful. Almost 2 years long now, why ? Not a complain from me, but a real question, as I, like others, am facing that bug in my everyday work. Everyday.
According to this comment in my bug (dupe to this one), there is a patch available: https://bugs.documentfoundation.org/show_bug.cgi?id=109227#c3
(In reply to internationils from comment #12) > According to this comment in my bug (dupe to this one), there is a patch > available: > https://bugs.documentfoundation.org/show_bug.cgi?id=109227#c3 Badfully, I gave it a try with master sources updated after 27/07 (see comment 10) and I could still reproduce this. Caolán: thought you might be interested in this one since you fixed tdf#109227
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f394b313ad9eac459e4765a639410ebd9278351a Resolves: tdf#99286 for jpeg dpi use apis that know about MapUnit::MapPixel It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=939538e6a8d35c8ab4412908482feb053386bf3d&h=libreoffice-5-3 Resolves: tdf#99286 for jpeg dpi use apis that know about MapUnit::MapPixel It will be available in 5.3.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=63de59a18360b4415a23ff76b4373f0afadd9840&h=libreoffice-5-4 Resolves: tdf#99286 for jpeg dpi use apis that know about MapUnit::MapPixel It will be available in 5.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On pc Debian x86-64 with master sources updated today, I don't reproduce this anymore the initial bug. However this part is still here: "if I compress a first time and I try a second time, the value didn't change (still 96dpi instead of 200 dpi)" but it's another story.
After fix it still seems to work wrongly (through better than before). However, I am not sure whether the nature of that problem is really related. So I submitted another report: bug 113116 (feel free to close that as duplicate and reopen this if needed).
*** Bug 113116 has been marked as a duplicate of this bug. ***
Can you try it with a fresh build from the master: http://dev-builds.libreoffice.org/daily/master/ Changed the status to REOPENED
@DietarPraas, I tried http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/master~2017-10-13_22.43.31_LibreOfficeDev_6.0.0.0.alpha0_Linux_x86-64_deb.tar.gz — it happens to be the same (i.e. better than before fix, but still wrong). If you wish, you can try it yourself on the https://bugs.documentfoundation.org/attachment.cgi?id=136970, which is attached to the bug 113116.
> it happens to be the same I meant "the same AS IN 5.4.2.2".
reopening fixed bugs is a terrible idea, please just open a new bug if there is a problem, even if its similar to an old bug, feel free to reference the old bug in the new bug