Description: Writer wrongly prints comments on text ranges. The commented text range does not match the shaded area in the print-out. The shaded area is offset. Steps to Reproduce: 1. Open attached file 2. Print file via: File -> Print -> go to the tab "LibreOffice Writer" -> choose the setting "Comments: Place in Margin" Actual Results: The result does't look right. The shaded area of the commented range is offset horizontally and (slightly) vertically. It doesn't matter whether it is a paper print-out or whether the file is printed as PDF. Both wrongly display the shaded area. Expected Results: The print-out should look like on screen: The shaded area should match the commented text range. Reproducible: Always User Profile Reset: No Additional Info: System: Ubuntu 20.04 Gnome LibreOffice version: Version: 6.4.6.2 Build-ID: 1:6.4.6-0ubuntu0.20.04.1 CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
Created attachment 168069 [details] Writer file: Comments on text ranges wrongly printed.odt
Created attachment 168070 [details] PDF printout: LO 6.4.6 on Linux. Comments on text ranges are offset and wrongly printed.pdf
Created attachment 168071 [details] PDF printout: LO 7.0 on Windows. Comments on text ranges are correct, but comment itself is half-printed.pdf The result on Windows 10 is much better, but not perfect. The text range is alright, but the comment is only half-printed. Windows 10 Version: 7.0.1.2 (x86) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-US Calc: CL
Created attachment 168072 [details] PDF printout: LO 6.4.6 on macOS. Everything is okay, no problem.pdf Interestingly, on macOS, the print-out is perfect. There is no issue. System: macOS Version 10.15.7 LibreOffice Version: 6.4.6.2 Build-ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115 CPU-Threads: 4; BS: Mac OS X 10.15.7; UI-Render: Standard; VCL: osx; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
I feel free to add Caolan to this bug. If I remember correctly, he had implemented the feature to attach comments to text ranges. Please remove yourself, if you don't want to be CCed on this bug. I also added bug 79232 to "See Also". That bug might be related, but there the problem also exists on Windows.
I can't confirm this bug.Reprodused on Windows 10 Everything is saved correctly
On Ubuntu 21.04 I still can confirm this bug. The text range is still off-set. Version: 7.1.4.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.1.4-0ubuntu0.21.04.1 Calc: threaded
Repro 7.3+ Linux. OK in Windows. The shaded area of the commented range is offset - implementation error from 4.3 when it was introduced, still repro in GTK3, GEN, SKIA. If a tester doesn't reproduce with Win, s/he should still test Lin, since reprtoed for Lin. There's another bug for comment text, I'll report as a separate regression and See Also that.
with https://cgit.freedesktop.org/libreoffice/core/commit/?id=c4dc91f5f2a7e04926070bbaabcd58ce85bb516d reverted the area is shown correctly in printout, but then missing in the preview so its something to do with how MetaFloatTransparentAction is handled
Looks like our problem is pdfwriter_impl2.cxx, case MetaActionType::FLOATTRANSPARENT, "special case constant alpha value" branch
https://gerrit.libreoffice.org/c/core/+/124714
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ab908e94da9305d6800c82b5d753c26193aa96b Resolves: tdf#138826 adjust the aTmpMtf to get drawn at maPos of Action It will be available in 7.3.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.
seems good in trunk, will let it sit for a while before considering a backport