Bug 150102 - LibreOffice Impress has white line on bottom and right edge of projection monitor
Summary: LibreOffice Impress has white line on bottom and right edge of projection mon...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.3.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0
Keywords: bibisected, bisected, regression
: 150840 151022 (view as bug list)
Depends on:
Blocks: Slide-Show
  Show dependency treegraph
 
Reported: 2022-07-22 11:10 UTC by NoWorries
Modified: 2023-11-24 10:58 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
This graphic shows the Lines produced by LibreOffice Impresss (10.54 KB, image/jpeg)
2022-07-22 11:10 UTC, NoWorries
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NoWorries 2022-07-22 11:10:39 UTC
Created attachment 181375 [details]
This graphic shows the Lines produced by LibreOffice Impresss

An Impress slide with a black background shows a white line along the bottom edge and another along the right edge of the projection screen. This is produced using LibreOffice Impress 7.3.5.2 on Kubuntu 22.10 with Plasma X11 or Wayland.  The same screen output is also obtained using Kubuntu 22.04 and LibreOffice Impress 7.3.4.2 with either plasma and X11 or Wayland.

This problem is easily produced by starting LibreOffice Impress with a blank screen.  Select Slide Properties > Background > Colour and then choose Grey A200 for the new colour and complete the colour selection. You should now have a black screen. Select F5 and you should then see a black screen with a white line along the bottom and another on the right edge.
Comment 1 Timur 2022-07-27 08:06:25 UTC
Seen simply by setting color to Black, also in Windows with single monitor, 7.5+.
Comment 2 Timur 2022-07-27 08:38:56 UTC
commit a9f6d98859321e1b9029acc0c6e9347f4c1cf3b7	[log]
author	Armin Le Grand (Allotropia) <Armin.Le.Grand@me.com>	Jan 31 2022 
committer	Xisco Fauli <xiscofauli@libreoffice.org>	Feb 11 2022
tdf#126319 Corrected bitmap creation from metafile

Armin please see.
Comment 3 Rafael Lima 2022-07-27 11:24:43 UTC
I was also able to reproduce this bug.

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 5df1bb4b1b222be00d25097660c4ee33542896ea
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL

Also repro in

Version: 7.3.4.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.4-0ubuntu0.22.04.1
Calc: threaded

NOT REPRO (works as expected)

Version: 7.2.5.2 / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded
Comment 4 NoWorries 2022-08-01 12:05:21 UTC Comment hidden (obsolete)
Comment 5 Rafael Lima 2022-08-01 13:27:54 UTC
(In reply to NoWorries from comment #4)
> I have found that the problem with the line on the bottom and right edge go
> if the Slide Format "On-screen Show (16:9)" is selected.  This works on the
> Kubuntu 22.04 LTS with X11 and Wayland Plasma selected.
> 
> Unfortunately on the Kubuntu 22.10, the lines are still present for both X11
> and Wayland. I hope this will be fixed in future updates.

I wouldn't set this as FIXED because there was not direct patch to address this issue.

Moreover, something changed from 7.2 to 7.3 that caused this white line to appear. Note that in 7.2 the default option for slide format is "Screen 16:9" and in 7.3 the default option is the same, but with different result.

Let's leave it as NEW for a while to see what happened that caused this problem.
Comment 6 NoWorries 2022-08-15 00:28:43 UTC
I now have LO Impress Version 7.4.0.3 and on Wayland Kubuntu 22.10 it is working correctly with no white lines on the screen edges showing.  I have the Format set to On-screen Show (16:9) and I make sure that no packages such as libreofice-kf5, libreofice-kde5, libreoffice-kde4, and libreoffice-kde are NOT installed.
Comment 7 Timur 2022-08-15 09:46:09 UTC
Reporter, Fixed is wrong status, do not set.
Comment 8 Mike Kaganski 2022-09-07 06:41:01 UTC
*** Bug 150840 has been marked as a duplicate of this bug. ***
Comment 9 Mike Kaganski 2022-09-07 06:45:04 UTC
Introduced by commit 4d535c4f867d86d40786788e5e5c9fd061a65673 (which was a master commit; the commit identified in comment 2 was a backport; mentioning the master commit to ease searching for related bug reports).

Repro with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 922b79a0f5a9151a6870ba395abcac5b54055275
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL threaded
Comment 10 Armin Le Grand 2022-09-07 14:44:56 UTC
Took a look. Due to https://bugs.documentfoundation.org/show_bug.cgi?id=126319 and that originally integer-based version GraphicExporter::GetGraphic and it's hairry adaption to do the right stuff in int-based metafiles it is *very* dangerous to scope around with it.
If so, it is *urgently necessary* to keep the tests from https://bugs.documentfoundation.org/show_bug.cgi?id=126319 working, especially the file and what to do from https://bugs.documentfoundation.org/show_bug.cgi?id=126319#c19.
I debugged what that black BG only does - it looks luckily it uses the !bSingleGraphic path in GraphicExporter::GetGraphic while the conversions from the previous task use the single-obj Metafile creation.

So I experimented with that and it seems that adding aOnePixelInMtf by
(a) removing from origin, see aOutMap.SetOrigin and
(b) adding to Size, see SetPrefSize(aBoundSize)

is too much. It looks like in aBound is the PageSize-1 (here locally I get 0/0/27999/15749), so to get the correct Size correcting by adding '1' should be enough, no need to expand by half a pixel-size. That is theoretically also good, and on the safe side, but seems to be too much at places where the Metafile gets interpreted, in this case SlideShow.
Unfortunately this is the UNO API Metafile-export, so a whole lot of consumers might interpret in a whole lot of ways..sigh.

What is true is that the correct integer size (here: 0/0/28000/15750) of the Page (and thus the fill of it) is more correct, so it's worth a try to correct just that.

I tested the exports (selection) of the example above, it gets not changed. So I do some more checks and might then dare to change that...
Comment 11 Armin Le Grand 2022-09-07 14:56:28 UTC
Suggested fix at https://gerrit.libreoffice.org/c/core/+/139596, please have a look and try it. The more situations it is tried in, the better in this case.
Comment 12 Commit Notification 2022-09-08 07:47:21 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/392b2cd4889cf944ed47b3473c6dd2cc1f89e7e7

tdf#150102 Correct PrefSize for UNO API Metafile exporter

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.
Comment 13 Armin Le Grand 2022-09-08 08:54:30 UTC
Had to do one more change, see https://gerrit.libreoffice.org/c/core/+/139033 or commit 28223ab9198e693a1cb4e344f14f8f5d5fbf127a.
Comment 14 Timur 2022-09-13 14:44:47 UTC
Verified in Windows for a single monitor, should not be different with two.
.
Comment 15 Timur 2022-09-17 15:46:09 UTC
*** Bug 151022 has been marked as a duplicate of this bug. ***
Comment 16 Mike Kaganski 2022-09-20 12:28:52 UTC
(In reply to Timur from comment #14)
> should not be different with two.

I wouldn't bet on it ;)
Some code is drastically different when using one monitor vs. multi-monitor ( see https://opengrok.libreoffice.org/xref/core/vcl/win/app/salinfo.cxx?r=970b87bb&mo=2939&fi=85#85 ). Not claiming that your results must necessarily be different on multi-monitor system, just mentioning that it's not granted :)
Comment 17 Timur 2022-09-27 13:43:22 UTC
Looks good to me with second monitor.
Comment 18 Thomas Neumann 2022-09-27 15:09:36 UTC
I still have the lines ( win10/64 two monitors) with the master 0d3dd0aa54ad792f91d0905f3d46c13df3512d89
Comment 19 Stéphane Guillou (stragu) 2023-05-05 13:05:42 UTC
*** Bug 155156 has been marked as a duplicate of this bug. ***
Comment 20 NoWorries 2023-05-07 05:13:28 UTC
You have got to be kidding if you think this problem is fixed.  It is certainly very obvious on LO Impress 7.5.2.2 on Kubuntu 23.04.

Yesterday I found a way to obscure the white line on the right and bottom edge of all of my projection slides, ie 61 of them!!!!  For my slides, I use Widescreen with dimensions 33.87 cm x 19.05 cm.

To remove the lines from LO Presentation projections, I made a jpg file of a Black screen with dimensions 34.10 cm x 19.20 cm. I then pasted this black screen on each slid in turn.  For this box, I then used Position X 0.00 cm and Position Y -0.04 cm with Width  34.10 cm and Height 19.02 cm.  After doing this, I used Arrange to send the this box to the back.  After doing this for each slide, I then had covered all white lines.
Comment 21 Mike Kaganski 2023-05-07 05:19:48 UTC Comment hidden (off-topic)
Comment 22 Mike Kaganski 2023-05-07 06:05:52 UTC
(In reply to NoWorries from comment #20)

Unfortunately, your bug report was hijacked from you. Likely, already comment 1 was off-topic, starting to discuss a new Windows problem; and since then, a different problem was tracked here, its cause was found, and fixed.

This shows how dangerous it is to assume that similarly-looking problems on different OSes are same. See comment 16 (which discusses a different aspect, that a problem on single-monitor system can be different from similar problems on multimonitor, but the principle holds).

Since your problem is obviously not the one that was tracked and resolved here, your issue is (likely) a duplicate of tdf#70976. You are advised to track that bug. This issue, however confused, should still be dedicated to the bug that Armin introduced and fixed, because this bug number is present in the respective commit message. Closing your bug as a duplicate of that older one at this point would only create still more confusion..
Comment 23 NoWorries 2023-09-12 06:52:22 UTC
When using LO Impress for projection, you need the presentation to be on a separate Monitor or Projector.  This is necessary for controlling the projection advancement and control. So it is always necessary for LO Impress to work with an external monitor.

The dates on one of the duplicate references was 2013 and the LO Impress version was in the 4 series.

I am currently dealing with LO version 7.5.6-rc2-0ubuntu1 on Kubuntu 23.10 and 23.04.  This version still has a white line on both the right edge and bottom edge of the projection screen.  These systems are on a Laptop with an AMD video card.

This problem only exists with an AMD video card.  I have a system with a NVIDIA video card and on this system there is no white line present on the projection screen edges
Comment 24 NoWorries 2023-09-20 03:00:43 UTC
I now have LO Presentation Version 7.6.1-rc2-0ubuntu2 and this still has the white line on the right edge and bottom edge of the projection image.  This only occurs with an AMD video card on my HP Spectre x360 15-ch004ng.

If you consider this problem to be fixed, could you please tell me what I must do to remove the white lines on the projected image.
Comment 25 Armin Le Grand 2023-11-24 10:57:46 UTC
You would have to change the presentation slideshow to not work on metafiles, but use primitives. The problem is numerical involving integers and view transformations. Until that is changed it's a balancing act to get that work well on 'most' systems, it's just dangerous to do changes there, the probability to make it worse is high. Note that those transformation calculations depend on many in-between things including target resolution(s), not even so much the system running on. It may look different for each discrete target solution.

The problem is known, the solution is what I wrote above, filed as tender since years. You might do it or try to get support and someone to do it, it's open source.