To demonstrate this bug, I create a writer document with a single line of text, e.g.: these lines should be evenly spaced and then copy/paste the line enough times to fill about ten pages of text. Then I scroll through the document using the scroll wheel on my mouse. Everything more or less looks fine, but if I hit CTRL-Shift-R (Restore View), some of the lines shift a bit, probably just 1 or 2 pixels. After this, everything is fine until I scroll again. In real world documents, I'll often see lines that are not only shifted but visibly clipped (perhaps shifted and then overdrawn by a neighboring line?). Occasionally I'll see a line that's half okay, half shifted. I thought this used to happen also with page-up and page-down keys as well, but I can't reproduce it that way right now. I also thought the problem seemed to ease up a bit with 3.3.0rc2, but I can't swear that that's the case, maybe I just went through a period of light scroll wheel use. In case it's relevant, I'm running Fedora 14 with the latest updates and a recent version of the proprietary NVIDIA driver. I also see the problem on my work machine, which is Ubunutu 10.04, also running the nvidia driver. I would be happy to help debug this if someone will give me an idea where to start looking. The last time I tried (pre-LibreOffice), I found it difficult to get oriented because most of the comments and function names were in languages I don't read well. But if it turns out that the relevant files have some English in them, I might be able to contribute.
Of course I can't reproduce ( but then again I am not using the proprietary nv driver ) caolan, any ideas, I think you have looked at such strange bugs before, please reassign back to the list though if you don't feel you are can help with this one
Nah, unless it happens with e.g. nouveau then its not IMO worth investigating given the complexities of dealing with the proprietary driver
> Nah, unless it happens with e.g. nouveau then its not IMO worth investigating > given the complexities of dealing with the proprietary driver I've switched back to nouveau on one of my Fedora 14 laptop, and I still see the issue with nouveau. I have noticed, though, that it seems to be sensitive to the document's magnification -- I couldn't demonstrate the issue with magnification at 100% or 160%, but it's easier to reproduce with magnification set at 175, 165, 164, or 105. After a bit of playing around, I haven't seen an obvious pattern. In case it matters, I used the right hand side of the trackpad to scroll this time, I didn't have a mouse handy.
Now that I'm paying more attention, I can add that I also see this without using the trackpad/scroll wheel to scroll, but just the right scroll bar. At the moment, possibily because of a lucky combination of magnification and the details of the document I'm editing, it's easy to produce -- every time I scroll to a different part of the document, I see a lot of rendering errors. I don't see the same behavior if I use page-up/page-down.
[Reproducible] with "LibreOffice 3.3.0 RC4 - WIN7 Home Premium (64bit) German UI [OOO330m19 (build 6 / tag 3.3.0.4)]" I created a Lorem Ipsum document as sample (pls. see attachment). For me with my PC 64 bit AMD Phenom II X4 955 Processor 32.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430 It is reproducibel in the followint way: 0. Open document 1. make sure that Auto Spellcheck is disabled and caret is at the beginning of the text. 2. click scroll down button at the bottom end below scroll slider, so that document scrolls line by line. Keep mouse button pushed for several seconds, until you will have reached page 3 3. <Ctl>+<shift>+<r> to restore view expected: scroll should have worked in a perfect way, nothing to restore actual: before you will have restored, many of the characters will have looked a little blurred or scraggy. When I restore view, I see the reported effect, and afterwards everything looks perfect. Reproducibilty seems to be better with soft scroll activated Unchecking antialiasing and hardware acceleration seems to be without influence
Created attachment 42733 [details] Pls. see Comment 5
For what it's worth, it appears to be insensitive to playing with the following options: "Screen font antialiasing," "Use hardware acceleration," "Use Anti-Aliasing," "Smooth scroll," and all of the writer compatibility options that have to do with spacing. I've tried many others as well, these seemed the most relevant. However, so far I've been unable to demonstrate it in Web Layout mode, only in Print Layout mode. In case it matters, I can verify that this bug remains easy to demonstrate in 3.3.1rc2. That doesn't seem to be an option in the drop-down above, but I've updated it to 3.3.1rc1. I'll probably make another attempt to find the relevant code soon. If anyone has any suggestions where to look, that would be helpful (last time I checked, there was a language barrier issue).
For the record, this bug remains in full force in 3.3.2. I've now had the opportunity to observe it with both free and proprietary drivers on both ATI cards and NVIDIA cards (all Linux). So I think it's safe to say that it's not a driver issue. I've also updated the architecture to "all" because I've seen it on both x86 archtectures, and there doesn't seem to be a way to select just two.
<http://wiki.documentfoundation.org/BugReport_Details#Version>
My mistake in mis-understanding the version field. This bug occurs on all versions of LibreOffice Writer (and of OpenOffice going back at least 3-4 years), so I've marked it 3.3.0b2.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This bug persists in 3.5.0beta1, observed on a 64-bit Linux build.
I have a similar problem when viewing documents in LibreOffice Writer Version 3.6.5.2 (Build ID: 5b93205). Some lines are blurred when scrolling in Web Layout View and they cannot be readable. Must switch to Print Layout View in order to read these lines.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
No repro -> WFM. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI Ubuntu 14.10 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4