Description: Make better bitmap export quality to PDF for Redaction Now we don't have any options for quality of bitmap export to PDF when we use Redaction function Steps to Reproduce: 1. Try use Redaction function 2. Look at result PDF (looks ugly) Actual Results: result PDF after Redaction function looks ugly Expected Results: result PDF after Redaction function looks fine Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 150332 [details] Example of Redaction PDF
@Muhammet kara, any opinion here ?
(In reply to Roman Kuznetsov from comment #0) > Description: > Make better bitmap export quality to PDF for Redaction > Now we don't have any options for quality of bitmap export to PDF when we > use Redaction function > > Steps to Reproduce: > 1. Try use Redaction function > 2. Look at result PDF (looks ugly) > > Actual Results: > result PDF after Redaction function looks ugly > > Expected Results: > result PDF after Redaction function looks fine > > > Reproducible: Always > > > User Profile Reset: No > > > > Additional Info: Could you please share the source document so tha twe can reproduce?
Setting to NEEDINFO. @Roman Kuznetsov, please provide the info from comment 3
If I understand the redact process correctly, there the pdf export is rather to print as pdf so that the text can't be selected in the resulting pdf. Best regards. JBF
Created attachment 154033 [details] Sample ODT with chart While it's not the same doc, I added a pie chart to a simple document, and got a similar sample.
Created attachment 154034 [details] Redacted PDF of sample Here's the redacted PDF output (nothing is covered).
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd6780aae1392d4c1af0b15b311a4966834a9602 tdf#124377: enable anti-aliasing metafile during redaction It will be available in 6.4.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.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/190f0621c2f799e5f44599ae93339aa93c9b9237 tdf#124377: enable anti-aliasing metafile during redaction It will be available in 6.3.3. 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.
*** Bug 127969 has been marked as a duplicate of this bug. ***
*** Bug 128089 has been marked as a duplicate of this bug. ***
Aron, is this bug fixed?
My change enabled anti-aliasing during redacted PDF export. Being the reporter, please check with a recent daily build, and judge for yourself (the description gives little help in evaluating the results). Personally I'd say the font is still a bit blurry. The problem is that when exporting the metafile to bitmap, I found no option to set DPI in the code, but I didn't spend a lot of time digging around.
Thank you for directing me to this bug report, Roman. I have tested the latest dev version, shapes are now nicely smoothed out around the edges, but I wouldn't consider the bug "fixed" without getting the resolution sorted, for printing this is still not close to being enough. IMO, in case of PDFs that consist of images (scanned documents) the program should detect the resolution of the image and automatically use that resolution for the output file. For PDFs that only contain text, the user should be prompted for resolution, with the default option being (again, IMO) at least 200 DPI. This feature should also know how to properly handle images with text (eg. scanned documents with invisible text applied over them for accessibility/WCAG purposes), but I think that's subject to another bug report :)
Dear Roman Kuznetsov, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have confirmed the issue on the latest version of LibreOffice. Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded I am attaching a PDF redacted using this version of the program for reference.
Created attachment 175733 [details] Redacted PDF of sample, done on version 7.2.1.2
Let's close as FIXED by comment 9 in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2a217a80bf383ddab0a5e0959ab2fd907dfd3406 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded the PDF result looks much better than my example and I'm not sure could we do it better than now
Let's reopen, I'm sure this could be improved in some way, but I haven't looked into it myself.
*** Bug 158234 has been marked as a duplicate of this bug. ***
There is another part of problem. The redacted PDF quality is affected badly by low DPI. However, there isn't a way to set the DPI. I would expect to have it at least in Options, if not in Save dialog.