Created attachment 132715 [details]
Example of artifacts, small slanted lines, left behind when moving around a mixed RTL-LTR paragraph.
It seems that fairly recently, LibreOffice acquired an interesting feature where if a certain paragraph has two different directionalities - e.g., an RTL paragraph with an LTR word, or LTR paragraph with an LTR word - when you move around this paragraph with the cursor keys, the cursor appears not just as a thin line (as it previously was), but as a thin line with a small triangular "head" pointing to the direction depending on the directionality of the part of the paragraph you are on.
So far so good. But the bug is that as you move the cursor, small bits of this arrow are left behind on the display, looking like tiny slanted lines. These lines do not disappear when the window is refreshed, but they do disappear if you go to a different page and return (i.e., they are obviously just display artifacts, not anything saved to the file).
I attach a typical example of the "scum" left on the display. Here I randomly typed a few English and a few Hebrew characters in the same paragraph, and used the arrow keys to move back and forth in that paragraph. You can see the result.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it.
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
As you asked, I'm attaching a tiny document which has one paragraph with both RTL (Hebrew) and LTR (English) text. If you move the cursor around this paragraph, with either the arrow keys or the mouse, you'll see part of the "head" of the directional cursor remain on the screen as you move around (as in the example image I attached previously).
Created attachment 132751 [details]
Tiny example document which has a paragraph with both RTL and LTR text and can be used to demonstrate the bug
I cannot reproduce.
What operating system are you using?
Did you try with 5.3?
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Arch Linux 64-bit, KDE Plasma 5
Build ID: 9348b322a5c230dfcc2231661b73e480b130fcd9
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 28th 2016
I am using Libreoffice 184.108.40.206 from the Fedora 25 package.
I did not try a newer version from what is available on my distro.
(In reply to Nadav Har'El from comment #5)
> I am using Libreoffice 220.127.116.11 from the Fedora 25 package.
> I did not try a newer version from what is available on my distro.
Ok, you can try it in parallel with a TDF release: https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Definitely in the current version (but unsure when it appeared) when I reach the end of any document and then try and scroll backwards the screen display part of the old screen and fails to overwrite with the new data so that it very quickly is unreadable. This can also happen as I scroll down through the document.
It certainly always happens when I reach the end. My footer appears several times at the bottom of my last page as an example.
My only fix is close and reopen. No data appears damaged but it is unusable until I restart.
As I said I don't know when this started but I am sure it must be quite recent.
I am trying to get to 5.4 version so I can see if it is still there.
I am not sure if this is related to the bug reports but this is the closest item I could find to my problem.
Hi all good news,
My problem appears to be fixed with 5.4. I managed to download it and when I did what I know still fails with 3.6 and it works fine.
The end of the file looks OK and back scrolling now works and the display looks fine.
Thanks for fixing the bug.
(In reply to Luigi from comment #8)
> Hi all good news,
> My problem appears to be fixed with 5.4. I managed to download it and when I
> did what I know still fails with 3.6 and it works fine.
> The end of the file looks OK and back scrolling now works and the display
> looks fine.
> Thanks for fixing the bug.
Nadav: do you get the same result?
Still happens in:
Build ID: 9050854c35c389466923f0224a36572d36cd471a
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3;
Locale: en-US (en_US.utf8); Calc: group
OS: Debian 64bit Stretch (Debian 9.2, with some backported packages)
I see vertical lines, rather than slanted lines, left over when moving the cursor right and left around the mixed paragraph.
Created attachment 137745 [details]
In version 6.0.0, the dirt appears as vertical (rather than slanted) lines.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker