Bug 112687 - Presentation annotations are saved with way too many points
Summary: Presentation annotations are saved with way too many points
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1 all versions
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0
Keywords:
Depends on:
Blocks: Slide-Show annotation(pen) 138293
  Show dependency treegraph
 
Reported: 2017-09-27 08:31 UTC by Antonello
Modified: 2025-06-25 00:00 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test slide with annotations (27.30 KB, application/vnd.oasis.opendocument.presentation)
2017-09-27 08:33 UTC, Antonello
Details
Screenshot of the same file (105.10 KB, image/png)
2017-09-27 08:37 UTC, Antonello
Details
Same document with both "kinds of ink" (connected and individual lines) (33.83 KB, application/vnd.oasis.opendocument.presentation)
2025-05-19 14:32 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonello 2017-09-27 08:31:19 UTC
Description:
It is actually possible to save annotations made during presentation with the mouse pointer if the option "Mouse painter as pen" (in Slide Show Settings) has been enabled before starting the presentation.

The problem is however that the tool doesn't use the algorithm of the normal hand-writing tool used in slide editing mode: while in editing mode the hand-writing tool saves just a few dots and "builds" Bézier curves, in presentation mode the algorithm just save LOTS of micro points.
You can see an example in the attached screenshot and odp file: the curves in blue has been obtained with the handwriting tool in editing mode, those in red with the "same" (that is not) tool in the presentation mode.
The result is that even with a few annotations, the slides become unresponsive even on modern pc and generate other problems (e.g., annotation saved on the wrong slide)

Steps to Reproduce:
1. In Slide Show Settings choose the option "Mouse painter as pen"
2. Now starts a presentation and make a few annotations
3. Close (or end) the presentation

Actual Results:  
Annotation are now saved (as desired) with the slide but making too many points but are composed of way too many points that make instable LO (i.e., needs to be killed). Annotations may also appear on wrong slides.

Expected Results:
The annotations made during presentation should have used the same algorithm of hand writing during slide edit.


Reproducible: Always

User Profile Reset: No

Additional Info:
A similar bug already exists (https://bugs.documentfoundation.org/show_bug.cgi?id=51928), but it focus on presentation annotations not being saved.
While this one observes that annotations can actually be saved, but the process of creating them is bugged.

There is no easy workaround, so I leave this bug report  as normal.



User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Antonello 2017-09-27 08:33:32 UTC
Created attachment 136561 [details]
Test slide with annotations

In the attachment lines in blue has been obtained using editing-mode hand-writing tool, while lines in red with presentation-mode hand-writing tool.
You can see the differences if you click on them "edit points"
Comment 2 Antonello 2017-09-27 08:37:18 UTC
Created attachment 136562 [details]
Screenshot of the same file

Screenshot of the same file. I am uploading this, as opening the original file is ok, but as soon you try to do something with the red lines, it may make your pc unresponsive, so opening instead this screenshot is a safer option ;-)
Comment 3 Buovjaga 2017-11-01 16:40:56 UTC
Repro from scratch.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: af318eeb4e23694e17b09b902afb98ddf9da9b7b
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 1st 2017
Comment 4 Antonello 2018-10-08 07:32:14 UTC
Hello, I know it's not nice to ping a bug report without bringing any news, but this bug is pretty important for me as it would allow me to use LibreOffice for teaching in distant learning projects, and at the same time it should be fairly simple to solve for someone with knowledge of the internals of LO Draw, as it is a matter of applying an already know algorithm in the context of live slide annotations.

Is there any way I could investigate this bug further or be more precise in its description?
Comment 5 Buovjaga 2018-10-08 12:17:38 UTC
(In reply to Antonello from comment #4)
> Hello, I know it's not nice to ping a bug report without bringing any news,
> but this bug is pretty important for me as it would allow me to use
> LibreOffice for teaching in distant learning projects, and at the same time
> it should be fairly simple to solve for someone with knowledge of the
> internals of LO Draw, as it is a matter of applying an already know
> algorithm in the context of live slide annotations.
> 
> Is there any way I could investigate this bug further or be more precise in
> its description?

I think the description is clear enough, so the only way you could help is to dig into the code and provide a better algorithm. I don't believe this is a regression, I assume it has always behaved like this.
Comment 6 QA Administrators 2019-10-20 02:33:13 UTC Comment hidden (obsolete)
Comment 7 Antonello 2019-10-20 10:47:19 UTC
Still present in LO 6.3.2.2
Comment 8 QA Administrators 2022-12-18 03:20:49 UTC Comment hidden (obsolete)
Comment 9 Regina Henschel 2023-07-11 11:53:19 UTC
The problem still exist in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 81daca18b69d31995bcd56f804659318398c02e2
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded
Comment 10 Antonello 2023-07-11 12:10:16 UTC
It's really a pity this bur remains somehow hidden in the mass, as it is pretty serious for me, as it prevents me from using libreoffice to realise distance learning courses...
Comment 11 Regina Henschel 2023-08-13 16:49:30 UTC
In https://cgit.freedesktop.org/libreoffice/core/commit/?id=631964a2ce1da3fbbeb53a5550c0e6728ba644aa I have changed the creation of the persistent drawing so, that now the points which belong to one pen move in slideshow are in one object in edit mode. That does not solve the problem, that too many points are generated, but the handling is now easier in edit mode.

Generating of points is somehow related to time. When you move the mouse quickly, you get less points than moving the mouse slowly.

Generating of the points is located in virtual bool handleMouseDragged( const awt::MouseEvent& e ) in https://opengrok.libreoffice.org/xref/core/slideshow/source/engine/slide/userpaintoverlay.cxx?r=91ba9654#358
Comment 12 Antonello 2023-08-13 21:07:10 UTC
Thank you @Regina..
Is there any nightly build one can use on Linux to test?

As a general note, why reinvent the weheel and not just reuse the handwriting tool of slide editing ?
Comment 13 Buovjaga 2023-08-14 06:11:54 UTC
(In reply to Antonello from comment #12)
> Thank you @Regina..
> Is there any nightly build one can use on Linux to test?
> 
> As a general note, why reinvent the weheel and not just reuse the
> handwriting tool of slide editing ?

At the moment the daily builds are not being generated, but hopefully they will come back soon: https://dev-builds.libreoffice.org/daily/master/current.html
Comment 14 Commit Notification 2023-08-24 15:54:57 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/44c0f2da567b49ef8a539958a834f1bc841c2003

tdf#112687 Simplify polylines from slideshow annotations

It will be available in 24.2.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 15 Regina Henschel 2023-08-24 17:04:44 UTC
The patch reduces the amount of points. I know, that these patches are only a workaround, but I think it is better than the current state in LO 7.6.

Because it is only a workaround, I will not set this issue to fixed.

(In reply to Antonello from comment #12)
> Thank you @Regina..
> Is there any nightly build one can use on Linux to test?
> 
> As a general note, why reinvent the wheel and not just reuse the
> handwriting tool of slide editing ?

I don't know how to do it. The problem is, that the drawing happens in slideshow mode whereas the handwriting tool is used in edit mode. The "mouse as pen" tool is very old. There might be a reason, why the handwriting tool was not use although that already exists at that time.
Comment 16 Rafael Lima 2023-10-04 19:03:26 UTC
(In reply to Regina Henschel from comment #15)
> Because it is only a workaround, I will not set this issue to fixed.

Hi Regina, I tested your fix for this issue and it works quite well. Thanks.

The only thing I'd like to suggest is that the final set of lines be grouped together.

With the current implementation, after the user exits the presentation and clicks the annotation shapes, they end up moving just a line segment.

It would be nice to have all of these segments grouped... what do you think?
Comment 17 Regina Henschel 2023-10-04 19:55:46 UTC
(In reply to Rafael Lima from comment #16)
 
> Hi Regina, I tested your fix for this issue and it works quite well. Thanks.
> 
> The only thing I'd like to suggest is that the final set of lines be grouped
> together.
> 
> With the current implementation, after the user exits the presentation and
> clicks the annotation shapes, they end up moving just a line segment.

It should behave now so, that a line which the user has drawn with one mouse movement will become one object. If the user releases the mouse button a new line starts. That is similar to how the freeline tool works. Does it not behave that way for you? Could you please attach in that case the file the user gets after leaving presentation mode?

> 
> It would be nice to have all of these segments grouped... what do you think?

I have not considered such. However, I think it is possible.
Comment 18 Rafael Lima 2023-10-04 22:57:14 UTC
(In reply to Regina Henschel from comment #17)
> It should behave now so, that a line which the user has drawn with one mouse
> movement will become one object. If the user releases the mouse button a new
> line starts. That is similar to how the freeline tool works. Does it not
> behave that way for you? Could you please attach in that case the file the
> user gets after leaving presentation mode?

Forget about this... I had tested it wrong. You're right, it now works as the freeline tool now, which is the expected behavior.

> I have not considered such. However, I think it is possible.

The advantage of this is that when the user draws something that is not a single line (f.i. an arrow, or a word), then all of these lines are grouped together.
Comment 19 Alex 2025-05-19 14:32:22 UTC
Created attachment 200868 [details]
Same document with both "kinds of ink" (connected and individual lines)
Comment 20 Alex 2025-05-19 14:33:09 UTC
Not sure if I'm doing things correctly or I hit another strange bug, but - I'm currently testing some other things with the "mouse as pen"-feature, and I found that the different versions of LO (on different PCs) I have at hand to test seem to behave differently regarding the "kind of Ink" generated as well - which is why I'm commenting here.

In a presentation created with Version: 25.2.3.2 (X86_64) [1a], drawings are a large set of individual pieces, same for [2].
LOs [1b] and [3] create a single poline just as described here. Now, note that [1a] and [1b] are seemingly the same version of LO, but used on a different machines...

Is there any setting that would control that behavior?
One machine [1b, 3] actually is a notebook with touchscreen and a pen - but the drawings were both made using the mouse.

I added a test document which I edited with both "versions", where the difference can be seen.

Versions:
[1a]
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Flatpak
Calc: threaded

[1b]
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Flatpak
Calc: threaded

[2]
Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

[3]
Version: 24.2.7.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4
Calc: threaded
Comment 21 Alex 2025-05-19 15:08:48 UTC
I actually tested another version [1c] (see below). I still don't see any pattern here with versions, rather than how the input might be processed:

[1b, 1c, 3]: Laptop with Touchscreen and Pen (though drawings done with a Mouse) and a VM (emulated USB Tablet)
[1a, 2]: Mouse only


[1c] Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
Comment 22 Regina Henschel 2025-05-19 17:48:27 UTC
The first example file was generated with LO 5.1.6 at 2017-09-27. That version does not contain the fix. Already existing annotations are not affected from the fix because after saving they are ordinary shapes.

In the second example file, that was generated with LO 25.2,  I see no problem with too many points.
Comment 23 Alex 2025-05-20 07:12:57 UTC
Hmm, Ok I realize now that I misunderstood the explanations for this bug, sorry.

The one here was about the "number of points per drawing" (as in: 100s of individual points), not about "one line" or "a set of individual lines".

Yes, the number of points is significantly less, still - so the patch does work as intended. 

What I meant was the fact that in case #1 there's one line, and case #2 there's multiple lines. I still don't quite understand why, but I guess I better create a new report.