Created attachment 168544 [details] See lines 7, 8, and 9 for deformed text There is an extremely irritating issue with LibreOffice Writer 7.0.3.1 (I’m not sure if it was evident in the last version 6 because I just started using LibreOffice before the latest updates). When using the Cambria, Cambria Math, Liberation Serif, or Times New Roman fonts where, as you scroll through text with a mouse (usually when done so quickly—but not always), some lines of text will deform, elevate off the base line and therefore be crammed up against the head line (although it will still display the correct size in the format bar drop-down menu for font size), or seemingly partially double print letters one on top of the other with each slightly offset higher or lower than the other on the screen. I’ve noticed that the deformed text problem, for some reason, seems to almost always effect the 22nd line of text first (only when using the Cambria or Cambria Math fonts)—regardless of the document file size (although I have not witnessed this in documents of a single page), and thereafter sometimes random lines, or parts of lines, throughout the rest of the document. With the Liberation Serif and Times New Roman fonts, the effect is not as pronounced, happens less often, and is usually relegated to the first, second, and/or third line of text (as opposed to the 22nd line as mentioned above) and usually does not effect any other lines further down in the document. I have not seen this happen with documents that were converted from Microsoft Word to LibreOffice Writer—only documents originating in LibreOffice Writer, although that may be a coincidence because when I first started converting all my files over, that was when I was using LibreOffice 6. I have also not noticed this problem when scrolling with the aid of my laptop’s touch pad, but I rarely use that when writing documents other than perhaps emails. See end of this document for specifics on my computer, operating system, and mouse. One way to rid this annoying, all too frequent, irritant is to scroll the screen up or down so the errant line is out off screen, then scroll back. Another is to use the File>Reload function, but by default that takes you back to the top of the document, which is not what is wanted in this case. If you are currently editing the document, you can sometimes simply select the line or paragraph and that process in and of itself enlarges and/or straightens out the text back to normal—unless it’s in a bulleted list (then the only method that works is the scroll off screen technique). The problem is somewhat different when you use the paint brush feature, and specifically when you use the click and drag technique of highlighting the text you want to reformat instead of clicking on one word at a time (which is not what you want to do if you want to reformat an entire section of text). In this case, the text above, below, or beside the text you are trying to reformat (in this case, it’s not the entire line, as mentioned above) will deform. I have not seen this happen if you simply click on a word instead of clicking and dragging the mouse over a word or section. It also does not happen if you single click the brush feature to reformat just one word or entire selection (via click and drag). Here are a few things in the Tools>Options menu that seem to help, but they are not foolproof as you will still on occasion have these same issues (meaning this is in all likelihood just a coincidence). • In LibreOffice Accessibility, deselect Allow animated text (which seems to have been deleted in version 7.0.3.1 anyway, as there is seemingly no way to select blinking or scrolling text in Writer, although you might be able to do so in Impress). • In LibreOffice Writer View, deselect Smooth scroll (ironically, this checkbox seems to work backwards to that indicated because if it is checked and you place your cursor at the bottom of the vertical scroll bar and click it to quickly scan through the document to the point you are interested in, as opposed to clicking on the scroll bar handle and scrolling the document that way, it progresses very slowly and in a herky-jerky manner; but with the checkbox deselected, it works smoothly (why anyone would not want smooth scrolling is beyond me)). >> This should probably be treated as a separate issue. I am using an Asus X540SA laptop with Microsoft Windows 10 Home (10.0.19042). All my drivers are up-to-date, but specifically the mouse is an Insignia USB Optical Mouse set to scroll two lines at a time and to automatically move to the default button in a dialog box. I have it set to hide the pointer while typing. I have not selected the Click Lock option.
Tools -> Options -> view -> check force skia software rendering and press ok and restart.. Does this improve things.. still more a work around, I admit
(In reply to Telesto from comment #1) > Tools -> Options -> view -> check force skia software rendering and press ok > and restart.. > > Does this improve things.. still more a work around, I admit That's something I tried early on, even though the problem seemingly has little to do with rendering, but it didn't work. I tried every possible combination of the option settings, along with different fonts and font sizes, but to no avail. The weird thing is that in the Cambria font, the first occurrence of this deformed text is always on the 22nd line, but in the LibreOffice default font and New Times Roman, the first occurrence is either first line or both the second and third lines. Plus, it only happens on documents that originate in Writer--not those which were originally Word documents that were reformatted and saved as Writer documents. I keep thinking because it only SEEMS to happen when using a mouse that it must be a driver issue, but I have all my drivers up-to-date.
(In reply to spokanemagneto from comment #2) The weird thing is that in the Cambria font, the > first occurrence of this deformed text is always on the 22nd line, but in > the LibreOffice default font and New Times Roman, the first occurrence is > either first line or both the second and third lines. Plus, it only happens > on documents that originate in Writer--not those which were originally Word > documents that were reformatted and saved as Writer documents. I keep > thinking because it only SEEMS to happen when using a mouse that it must be > a driver issue, but I have all my drivers up-to-date. Any change to share an example file where it happens.. I assume you tried safe mode/ profile reset i'm also thinking in the area of font versions etc.. or i'm totally off.. adding Stuart
What you show is screen tearing, extending horizontally across entire lines of text as the document canvas is redrawn with scrolling (by mouse, touch pad, or cursor arrows). It has nothing to do with font metrics and the rendering of the fonts. Likewise it probably has nothing to do with your mouse hardware & drivers (the scroll size is not read from your mouse settings, rather from LO program settings). Skia rendering is enabled by default with the Windows builds. You must explicitly disable it to revert to "default" GDI based rendering by CPU (with optional CPU controlled Hardware Acceleration). We need to know if the tearing continues when you eliminate Skia and switch to GDI rendering. Also, we need to know your graphics hardware, so before disabling Skia--with Vulkan rendering enabled--copy the contents of the Skia.log from %APPDATA%\LibreOFfice\4\cache\skia.log and if present the opengl_device.log
(In reply to V Stuart Foote from comment #4) > What you show is screen tearing, extending horizontally across entire lines > of text as the document canvas is redrawn with scrolling (by mouse, touch > pad, or cursor arrows). > > It has nothing to do with font metrics and the rendering of the fonts. > Likewise it probably has nothing to do with your mouse hardware & drivers > (the scroll size is not read from your mouse settings, rather from LO > program settings). > > Skia rendering is enabled by default with the Windows builds. You must > explicitly disable it to revert to "default" GDI based rendering by CPU > (with optional CPU controlled Hardware Acceleration). > > We need to know if the tearing continues when you eliminate Skia and switch > to GDI rendering. > > Also, we need to know your graphics hardware, so before disabling Skia--with > Vulkan rendering enabled--copy the contents of the Skia.log from > %APPDATA%\LibreOFfice\4\cache\skia.log and if present the opengl_device.log Ah, the term tearing explains it perfectly. Why I didn't think of that term, I don't know. I found another possible bug in that when I checked for updates, it would tell me I am current--but I found out that there was a newer version (7.0.4.2), so I updated, but that did not fix the problem. I also tried running it as an administrator (even though I only have one account, an administrator account), but that did not fix the problem either. I thought I was onto something when I deselected the Math baseline alignment under Tools>Options>LO Writer>Formatting Aids, but this morning I checked and the checkbox was once again selected--and the tearing problem was back, even though I had pressed Apply and OK the evening before. The %APPDATA%\LO\4\cache\skia.log file that you requested only contained these two lines of text: RenderMethod: raster Compiler: Clang There was on opengl_device.log file. After the change to deselect Skia, which I had done before without it fixing the problem, the %APPDATA%\...\skia.log file contained the following: DriverVersion: 20.19.15.5107 DriverDate: 11-15-2019 DeviceID: PCI\VEN_8086&DEV_22B1&SUBSYS_10C01043&REV_21 AdapterVendorID: 0x8086 AdapterDeviceID: 0x22b1 AdapterSubsysID: 0x10c01043 DeviceKey: System\CurrentControlSet\Control\Video\{BCDC4E8B-D8FD-11EA-918F-B232891AD31F}\0000 DeviceString: Intel(R) HD Graphics The dramatic difference in file size makes me think I might have messed up when I copied the file before the skia change (perhaps LO has to be open at the time, and I cannot remember if I had opened it before I hunted for the files you requested. So, I made the change from Skia to using the hardware accelerator, and the Math baseline alignment checkbox is again selected, and I it still fails. I did notice another clue, and that is that if I turn off the Toggle Automatic Spell Checking, then turn it right back on, the tearing text goes away without having to scroll the page up or down passed the torn text and then back again.
[Automated Action] NeedInfo-To-Unconfirmed
I'm not sure why this bug has not been assigned to anyone because it is most irritating and something that would turn potential users off to continued use of the LibreOffice product suite. At any rate, the issue with the tearing text still persists. Originally, I found that doing a reload would solve the issue, but that would bring you back up to the top of the document, which is not ideal because you might not remember exactly where you were in the document before resorting to that reload. The next alternative is to scroll the page up or down until the infected area is out of view, then scroll back. Considering how often this problem occurs, this is also not an ideal solution. Finally, I found another, more practical band aid, which is to click on the Toggle Automatic Spell Checking button. That eliminates the problem, at least, until the next time moments later. I just found that another approach that works is clicking on the button right next to it, the Toggle Formatting Marks. So, hopefully that brings everyone up to speed on this. Someone, please fix this. One person said it also happened with the touchpad and arrow keys, but I have only had it happen when using my mouse.
Created attachment 168758 [details] misregisterd line of text w/Skia raster rendering Reducing the document canvas y-height so text can move out of view port without the view crossing a page boundry, scrolling down & up with mouse wheel or scroll bar "thumb" a single line of text can be made to lose its registration--and the distorted "torn" text can move down or up out of view and return and still be distorted. But if moved far enough, or if the page scrolls to the next or prior page, the text run will be refreshed and no longer mis-registered. This occurs in a very low percentage of scroll movements <5% , but it does occur with GDI default mode rendering, and with both Skia Vulkan and Skia raster mode rendering. Did not check OpenGL rendering. Did not check if font changes affect percentage of the line tear. RenderMethod: vulkan Vendor: 0x8086 Device: 0x5916 API: 1.2.151 Driver: 0.402.591 DeviceType: integrated DeviceName: Intel(R) HD Graphics 620 Denylisted: no Version: 7.2.0.0.alpha0+ (x64) Build ID: 57a59ad02d2e5e89724c0d2e60cf6e7d99fba005 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
This is such a low percentage issue and the visual glitch on document canvas is transient, I don't see it as fixable. Perhaps when bug 103322 brings in floating point positioning and consistent subpixel rendering for the VCL canvas.
(In reply to V Stuart Foote from comment #9) > This is such a low percentage issue and the visual glitch on document canvas > is transient, I don't see it as fixable. Perhaps when bug 103322 brings in > floating point positioning and consistent subpixel rendering for the VCL > canvas. I am very disappointed to hear that you think this visual "glitch" is trivial and not fixable. Everything is fixable, and there is no such thing as a trivial functional glitch. I have used numerous word processing programs since they first came out--and not one of them ever demonstrated this sort of problem, and certainly not as routinely as this one does. The whole point of a word processing program is to facilitate the production of documents, so if the program by its very design causes the text in documents to twist, distort, and shrink in font size when simply scrolling through the document, this has to be considered a major malfunction. If the whole point of starting this open source program was to build something not only compatible with, but as good as, if not better than, Microsoft Office, then thus far you have failed. Like them, it seems you have spent too much time adding unnecessary bells and whistles that overly complicate the usage of the product. How many prospective users do you think are going to put up with this unnecessary irritant and distraction, especially professional office workers? Do you think the legal secretaries in a law office would put up with this? I can tell you from past, personal experience in the computer field service business the answer is not no but hell no. It is a shame really because it is obvious that you put an awful lot of work in developing this software, apparently all for nothing.
IMHO this transient visual glitch *is* trivial, bordering on a wontfix resolution. @Luboš, any comment on severity and potential to correct? Would floating point harfbuzz positioning actually offer improvement to what seems to be a VCL canvas issue?
I think taking this as trivial/wontfix is taking it too far, I can imagine this can be annoying when using Writer. I can't quite comment on the technical side though.
Thank you Luboš. I invested several hours over the course of several days trying to gain as much useful information as I could to aid in the troubleshooting of this problem. I admit that disabling Skia rendering has greatly reduced the frequency/repeatability of the problem, but it still does it occasionally. I also thought my observation that under certain repeatable circumstances it always affects the 22nd line of text first before subsequent random lines throughout the document, but under other (also repeatable) circumstances it always affects either the first or the second and third lines of text before any others. That to me is a pretty interesting detail that I am quite positive others would not have noticed because I am an exceptional electronic technician and rank amateur programmer who has worked with a great many others, both professional technicians and ordinary consumers, to know that you rarely get useful or accurate information and that you have to verify everything for yourself. At any rate, I also found clicking on the Toggle Automatic Spell Checking and Toggle Formatting buttons as a band-aid fix. The only thing I cannot attest to with this issue is that it also does it with the touchpad and the keyboard arrows. For me, I have only ever experienced it via the mouse, which is why I checked to make sure I had the most current version of the driver and then reloaded it just in case. Again, thank you. I am obviously very much behind LibreOffice's efforts to build a better office productivity platform to compete against the nameless 800-pound gorilla in the market, as well as all the other options available out there. If it turns out that it is a bizarre driver issue, then I will admit I raised an alarm unnecessarily, but when I am told that it only affects 5% of users, then I know that the problem is genuine no matter what the eventual fix is and I was not wrong in bringing to everyone's attention. I felt I was being dissed by being told that it was a trivial problem and won't be addressed. I never asked that he drop everything to work on it or that it would be easy to find it, but there is a big difference between can't and won't. The latter term nearly made me uninstall LO, but I was hoping someone else would at least give finding the problem a try. I know that is why I got into the profession. Using my talents and technical competency to identify and fix problems is the challenge that drives me--not routine issues that are easy to spot and fix.
(In reply to spokanemagneto from comment #13) > ... If it turns out that it is a bizarre driver issue, then I will > admit I raised an alarm unnecessarily, but when I am told that it only > affects 5% of users, then I know that the problem is genuine no matter what > the eventual fix is and I was not wrong in bringing to everyone's attention. > I felt I was being dissed by being told that it was a trivial problem and > won't be addressed. I never asked that he drop everything to work on it or > that it would be easy to find it, but there is a big difference between > can't and won't. The latter term nearly made me uninstall LO, but I was > hoping someone else would at least give finding the problem a try. I am sorry if you were feeling dissed--please it is not that at all, and thank you for taking the time to file a valid issue. But note this was *my* testing of the issue you raised, expending considerable time I did confirm it. It is trivial because it is *transient* and affects the VCL canvas on Windows builds. An assessment based on 10 years for doing QA review of issues on the LibreOffce and OOo. It has been set NEW--rather than confirmed and closed as WONT FIX, or being set NOT A BUG--and the lead dev working rendering issues notified. However, my exact wording was "This occurs in a very low percentage of scroll movements <5% , but it does occur with GDI default mode rendering, and with both Skia Vulkan and Skia raster mode rendering." You'll note not only did I test your submission, but also each of the other rendering paths, and not just mouse scroll but the equally valid drag to reposition the view frame with the 'thumb' on the scroll bar, while proving the cursor Up/Down and Scrollbar Up/Down movements are likely not equally effected. And losing view frame sync for a line of text at <5% of scroll movements was generous, it is probably closer to <1%. It is difficult to reproduce, and so nearly impossible to correct. I suspect it will be a y-height rounding issue affecting buffer of vertical blocks of text on the VCL document canvas. If there was a way to force it 100% by some combination of view port size, text size, and scroll distance--sure it could probably be solved. But as is it STR are too spurious to do anything with it.
I have an update. It did not make sense to me that only documents that I initiated in LO Writer would exhibit this text tearing problem, but then it occurred to me that the only documents that I noticed this problem was on those that had headers. Taking into account what you said about it probably being a rounding error, I also got to thinking about the crazy default margin settings LO Writer uses (such as 0.79" for the left, right, top, and bottom margins), whereas virtually all of the documents I brought over from Microsoft Word had margins of either 0.75" of 1.00". So, my thinking was that since 0.79" is not evenly divisible by 2, 3, 5, 7, or I don't know how many primes beyond that, I should change the Format>Page Style>Page settings for left, right, top, and bottom margins to 0.75" and the Header height to 0.05" (from the default of 0.04"). I was thinking of unchecking the header and footer height auto-fit checkbox, but that was not necessary because with just those page margin and the header height changes, I have not been able to get what was a fairly routine error to reoccur. Now that I've made that claim, later today it will fail--Murphy's Law, but I have tried repeatedly these past two days and not seen it. Let me know what you think. P.S. I'm sorry that I didn't realize it was only documents with headers before. Ditto the fact that I'm not sure if it was the header or margins changes, but I wanted everything to be evenly divisible by five (or some other prime number, so there would be no rounding errors).
Oh, and one other thing. The header correlation might explain why you have not had too many, or any, complaints about this text tearing issue. I am in the process of writing up notes on quite a few different technical subjects, which I created a template for (something I have never done before). Just a thought.
Murphy's Law struck once again, as I suggested it might. After the changes I made to my documents mentioned in my previous post, I discovered it does indeed still exhibit the text tearing problem--but not nearly as frequently or as perceptibly. And, for the first time, it occurred on a document that did NOT have a header. It still has never happened on a document that originated in Word. Still, turning off Skia and going with hardware acceleration and then changing the default page margins, tab settings, etc. so they were evenly divisible by five, things have progressively gotten better, albeit still unacceptable.
(In reply to spokanemagneto from comment #15) > I have an update. It did not make sense to me that only documents that I > initiated in LO Writer would exhibit this text tearing problem, but then it > occurred to me that the only documents that I noticed this problem was on > those that had headers. Any change to share the file in question.. I have seen some tearing.. While scrolling documents different (especially on certain zoom levels) on my mac.. but catching it in reproducible manner ... https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission
Eureka! I think I might have found the source of the text tearing bug! From the start, I thought there was something hinky about the margins because they were not where they should be after I set them. Being unfamiliar with styles and not particularly fond of the use of all these floating and sidebar decks impinging on my work area (until now), I gravitated toward using the good, old-fashioned, drop-down menus; e.g., Format>Page Style, and setting my document margins to 0.75″ there. However, after applying that setting, I found that the actual margins were set to 0.79″ instead. In delving into the Styles Deck (F11), I found a problem with the US measurements in the Page>Format>Margins section. If you select Narrow, Moderate, Normal (1″), Normal (1.25″), or Wide, the margins will be set accurately—as seen on the horizontal ruler and in the Format>Page Style drop-down menu. However, if you set the Margins to Normal (0.75″) in the Styles Deck, you will notice that the margins as viewed on the horizontal ruler and in the Format>Page Style drop-down menu reflect that the actual margins are set to 0.79″ instead! If you look at the horizontal ruler, you will see that the left margin is set at 13/16″ instead of 12/16″ (i.e., 3/4″) and the right margin appears to be set at perhaps something slightly over 13/16″ instead of 12/16″. Because I manually set the page margins from the Format>Page Style drop-down menu instead of via the Styles Deck, the Page>Format>Margins setting in the Styles Deck is then selected as Custom. Once again, this could be yet another case of Murphy’s Law, but this is an actual bug. Whether it fixes the text tearing issue or not remains to be seen, but when you mentioned it possibly being related to a rounding error, this is what lead me to pursue this avenue of investigation. I did some preliminary checking of the metric measurement settings, and the ones I checked seemed fine, but I did not check them all to verify they were measuring correctly. It has taken a while to get to this point, but this should be something that should be relatively quick and easy to fix. After that is resolved, we shall see if it fixes the text tearing issue. I am hopefully optimistic that it will. Until then, all I have to do now is to figure out how to change the Default Paragraph Style to reflect Moderate style page margins (which works fine except it has 1″ margins top and bottom, but that’s not critical to my purposes). Oh, this margin issue might also explain why this problem never occurred on documents originally done in Word, as in checking scores of those documents that were opened and resaved in the Open Document Text format once I made the switch to LibreOffice, they all had margins other than 3/4″.
(In reply to spokanemagneto from comment #19) I do repro this: 1. Sidebar -> Page 2. Format -> Margins, pick 1,90 cm or 0,75 inch 3. Menu Format -> page Style -> shows 2,00 or 0,79 inch. Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-US Calc: CL but obviously a different bug, maybe related.. but don't think it should matter
Well, you were right. It turns out that did NOT fix the problem...but it is a bug nonetheless. I spent another ten hours yesterday on this and found that it goes a little further than I thought (the weird margins settings). I uncovered some seemingly related issues. It appears that the reason for the weird margin settings, in particular those in the Normal (0.75") page format is that ALL the templates are set to A4 instead of Letter for those of us in the USA (why we are still living in the dark ages with regards to measurement standards is beyond me). I tried resetting the Language of..., Formats, and Default Languages for Documents settings from Default - English (USA) to simply English (USA), but that did not help. To address that issue, I ended up simply making a couple new templates, including a new default generic document template to use in the meantime, but they still exhibited the text tearing issue. So, in thinking about how everything seems to be geared toward evenly divisible cm units and thus perhaps causing the rounding errors when converting to inches, which was the suggested root cause of this text tearing issue, I decided to switch everything over to the standard points units (margins, tabs, line spacing, etc.) since that is what printers use. One template I created had a font size of 10, single line space, and 54-pt. (i.e., 3/4") side margins. If I switched from single space to a line space of 1.15 things improved, but it was still occasionally bad. I did some reading and found an author who suggested using the "magic number", which is to say making your measurements evenly divisible by your line spacing (or half the line spacing) number. Earlier, I was doing that, but with the font size--not the line spacing, which never occurred to me. He indicated that the default for LibreOffice is 12/14 (font 12, line spacing 14). He also recommended that if at all possible when setting the paragraph formats to use Fixed Line Spacing because it's a fixed size and not calculated (it also has the benefit of being register true without having to select that option as you otherwise would have to). With all that in mind, I kept the font size of 10, but changed to fixed line spacing to 14 (12 did not work, but 14 is evenly divisible by most of the other settings), and 54-pt. side margins. The default generic document template I created has font 12, fixed line spacing of 14, and margins of 72-pt (i.e., 1"). I spent an hour this morning trying to get either one of those templates to show any signs of text tearing, but I have not noticed any, but again, I know Murphy's Law is lurking nearby waiting to make a fool of me again, thinking I found it. So, the question is, even though the text tearing is still an issue, this is a legitimate bug in and of itself, so should this be posted elsewhere? Finally, I have a question. As a programmer hobbyist, if rounding is part of the issue (along with incorrect USA settings), then why not ditch the float data type and opt for a long long instead (providing you're using C++)?
(In reply to spokanemagneto from comment #21) I would still suggest to attach a example file which demonstrates the issue. The dis-alignment isn't unfamiliar to me. Have seen it on macOS for a while. But so unreliable to reproduce, making it hopeless exercise to attempt a tracing it back in older versions. The big question is .. is this a regression? But maybe kind of system specific/context specific.. So another approach would be you attempting an bibisect. https://wiki.documentfoundation.org/QA/Bibisect As it apparently happens more often in your case... FWIW: screensize & zoomlevel might be relevant too :P.. But still makes sense if this is a rounding topic..
In Windowed mode, the screensize of the LibreOfifce window likely matters too :P And probably even all present toolbars :-(
*** Bug 139836 has been marked as a duplicate of this bug. ***
Dupe bug 139836 means this is not Skia related, nor Windows only.
FWIW; how is scrolling done? Touchpad or Mouse?
The screen size and/or zoom level might be a factor, as I always use the page width setting with the sidebar minimized for maximum work space (i.e., 156%, versus with sidebar when needed at 119%). Either working with the sidebar permanently opened or reducing the zoom level to 100% was something I was going to play around with later today. Since I got onto this idea of line spacing being a possible cause, as setting the line spacing to "Fixed" and then selecting a value at least 2 points over the font size does seem to greatly reduce the occurrence of the text tearing issue (but it does not completely eliminate the problem, even with the margins and tabs all being evenly divisible by the line spacing setting (or divisible by a number such as 7.5, which should leave no rounding errors). In my reading up on the subject, I found this tidbit of information online that says that prior to the 4.2 release, LO used to allow users to set line spacing to 1/10th of a point (1/720th of an inch), but now you can only set it to the nearest point. Apache OpenOffice apparently still allows for 1/10th of a point. I have no idea if this is significant or not, but if the problem only arose after that release, then perhaps it is. One update. I had mentioned that documents that were originally written in Word before being converted to Writer, did not ever exhibit the text tearing issue; however, I was editing one such document yesterday and it started doing so--and doing so virtually every time I scrolled up or down, even if just a few lines. That document had line spacing set a "Single". BTW, is "Use superordinate object settings" really necessary if a document is completely written in one language, or is it used in Writer (don't recall ever seeing it in Word) to facilitate writing on an axis other than 90-degrees? I experimented with setting that to left-to-right, but to no avail with regards to the text tearing issue.
(In reply to Telesto from comment #26) > FWIW; how is scrolling done? Touchpad or Mouse? It happens with both the mouse and the touch-pad, which seemingly eliminates a driver issue...unless it's two driver issues. My drivers are up-do-date, but I know after the last two Windows10 major feature updates that there were issues that Microsoft blamed on bad drivers (despite those drivers working fine until their update), but I see that non-Windows users have experienced this same text tearing issue as well, so this probably cannot be blamed on the 800-pound gorilla.
My bug report was marked as duplicate (Bug 139836). So I'll share here a few more details in response to recent comments. 1) I usually scroll with the mouse wheel. 2) I am using Kubuntu (Kf5), but I'm quite sure I've had the same issue on Gnome too (Gtk). I'll keep an eye next time I use Gnome to see if this issue also happens there. Next week I'll test if this bug persists in LO 7.2 as well.
Created attachment 169139 [details] Images describing the issue Hi! So I spent some time using both LO 7.0.4.2 and LO 7.2 alpha on kf5 (Kubuntu) and I can confirm that the rendering issue persists in both versions. I attached a file with screenshots to better explain the issue. I noted a few things that might be relevant: 1) The issue does not appear up-front. It takes some time for it to appear for the first time. I noticed that if I just scroll up and down the file, nothing wrong happens. The issue only appears after something has been edited. However, the issue occurs seemingly at random and not very frequently. 2) When the issue happens on a given line (see attached ODG file for further explanation), if I select the line the issue moves to the next line. 3) Sometimes, the rendering problem is a bit different (see also the attached ODG file), Example 3. In this case, selecting the line does not fix rendering and it does not move to the next line.
Created attachment 169140 [details] Original ODT file where the screenshots were take This is the original ODT file I used to take the screenshots. I contribute to the Documentation team and this issue always arises when I'm editing user guides.
Very good observation. This could be why I originally thought documents that were originally formatted in Word and later reformatted to Writer were immune to the text tearing problem…because I was NOT editing them. Later, when I edited my resume, which was originally written in Word, it started exhibiting the symptoms virtually every time I scrolled even just a few lines (i.e., extremely repeatable). This also might be a clue, as my resume has a lot of formatting (headers, footers, indents, tabs, and tables). Earlier, I noticed the problem when working with files using my technical notes template, which also has a lot of formatting (two different type fonts, three different font colors, two different background fill colors, bullet and number lists, numerous tables, and a header), but I have yet to notice it when working in my default letter template (which has virtually no formatting except page margins, type font and size). I also verified that if you have a line of text that is tearing and you highlight that line, the problem self-corrects on that line…but transfers the problem to the next line. So, you either have to scroll up or down until the bad line is off screen, reload the page, click the toggle automatic spell checking or toggle formatting marks buttons in the standard menu, or click to display the sidebar. To sum up what has been discovered to this point: • it seems to happen less frequently if Skia rendering is turned off and hardware acceleration switched on • it has nothing to do with the chosen font • it seems to be less severe if the font size is ≥12 points • it seems to happen less often if the line spacing is set to fixed and is ≥2 points greater than the font size • it seems to happen less often with the zoom level ≤100% • it seems to only happen with documents at least two or three pages in length • it seems to happen less often if all font sizes, line spacing, margins, headers/footers measurements, tabs, page width and length, etc. are all evenly divisible (or leave a one- or two-digit terminating decimal number (to avoid rounding errors???)) • it has nothing to do with animated text, direct cursor, math baseline alignment, displaying hidden text or paragraphs, sidebar open (or not), synchronized axis in grid resolution, etc. • it seems to happen less often if the units of measure are NOT in inches • it seems to happen less often if you avoid using the Normal (0.75ʺ) format page margin setting because the margins are messed up (left margin actually at 0.79ʺ) • it seems to happen less often if you change the page format size to letter, as it should NOT be set to A4 for US (probably connected to the point mentioned directly above as the paper size width for A4 is not 8.5ʺ, but is 8.27ʺ One thing I have not had time to investigate is ODF File Format 1.3 Extended versus using an earlier version.
Update. Rafael Lima thought the text tearing issue only occurred after an edit was done on the document being scrolled. I had not noticed that detail, so I commented that I thought it was a good observation, but unfortunately just today I noticed the problem does occur without having done an edit. I was investigating a comment made about another bug I reported about the smooth scroll working backwards of the way one would expect, when I noticed that as I was scrolling without using the scroll bar or the up or down scroll buttons at the top and bottom respectively (just clicking inside an empty portion of the vertical scroll bar to quickly scan through a long document) that it will fairly routinely cause text tearing when you suddenly stop scrolling.
Created attachment 169304 [details] Screencast Certain up down shifting.. 1. For me it's double left clicking in the document 2. left mouse click & scroll down 3. Release mouse
Created attachment 169305 [details] Screenshot 6.0.4.1 OpenGL with same issue
It's also occurring in 5.3 and Versie: 5.2.2.1 Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: GL; Locale: nl-NL (nl_NL); Calc: CL Using OpenGL.. less success with GDI
Also in Version: 5.0.6.3 Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa-GL Locale: en-US (nl_NL) After some pushing.. FWIW.. and talking about the text shifting.. I'm not seeing real drawing glitches..
Created attachment 169306 [details] Screenshot 7200 master Double (or triple) clicking.. before starting selection.. after the selection done.. to deselect rather good in triggering the problem
(In reply to Telesto from comment #38) > Created attachment 169306 [details] > Screenshot 7200 master > > Double (or triple) clicking.. before starting selection.. after the > selection done.. to deselect rather good in triggering the problem Thanks for the series of observations you've made, especially that it also occurs in earlier versions.
(In reply to spokanemagneto from comment #39) It's likely in 4.3 too, have seen it happen on macOS. However never got a hold on it.. but looks like GDI isn't affected.. so needs testing on Linux/macOS. I speculate it can not be seen in 4.4.7.2 with OpenGL enabled because some weird timer madness.. Timer logic changed with 4.4.7.2 - 5.1 branch. Causing the issue to be more prominent.. but lingering around earlier on. It appears mouse clicks are triggering a (full?) layout refresh or something like that at some point.. With different offset of few pixels or even rounding?? Where the backend holding a different image of the page (shifting) compared to the 'paint buffer'. And clicking around triggers a paint buffer invalidation/ repaint) Where the difference shows up and incrementally resolved as screen refreshes in parts.. Leaving sometimes artifacts. But well that's my invented story of someone who has actually no knowledge the matter.
(In reply to Telesto from comment #40) > (In reply to spokanemagneto from comment #39) > It's likely in 4.3 too, have seen it happen on macOS. However never got a > hold on it.. but looks like GDI isn't affected.. so needs testing on > Linux/macOS. > > I speculate it can not be seen in 4.4.7.2 with OpenGL enabled because some > weird timer madness.. Timer logic changed with 4.4.7.2 - 5.1 branch. Causing > the issue to be more prominent.. but lingering around earlier on. > > It appears mouse clicks are triggering a (full?) layout refresh or something > like that at some point.. With different offset of few pixels or even > rounding?? Where the backend holding a different image of the page > (shifting) compared to the 'paint buffer'. And clicking around triggers a > paint buffer invalidation/ repaint) Where the difference shows up and > incrementally resolved as screen refreshes in parts.. Leaving sometimes > artifacts. > > But well that's my invented story of someone who has actually no knowledge > the matter. Well, it sounds plausible to me, but I'm an electronic technician by vocation and only a software programmer by avocation. I have more reading to do on OpenGL as initially I came away with the notion that it was primarily used for heavy graphics usage, which I would not think would affect a word processor, so I put that aside for the time being, but maybe I should look into downloading OpenGL.
Created attachment 169357 [details] Example file 1. Open the attached file 2. CTRL+A 3. CTRL+X 4. CTRL+V 4. Scroll up 5. Triple click "pour at the top of the page" 6. Nothing happening -> File reload -> Possible shift visible (not sure) 7. If not repeat 2-6 2 times.. it should have happened by now
Created attachment 169358 [details] Bibisect log Bisected to: ~/bibisect-50max$ git bisect bad 778edec7122780e071f932b19ed0eafe5db4523c is the first bad commit commit 778edec7122780e071f932b19ed0eafe5db4523c Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 16:52:23 2015 +0800 source-hash-378c74ce290ab772f962db51ff8cba200cb40144 commit 378c74ce290ab772f962db51ff8cba200cb40144 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Tue Dec 2 17:42:55 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Dec 2 17:45:21 2014 +0000 Only call super-expensive Invalidate on scrollbar toggling otherwise even using backspace in an annotated area will cause super slow behaviour as each keystroke causes a full page render This became a problem after commit 0761f81643a6890457e9ef7d913ab5c88c2593a4 Date: Thu Dec 19 18:50:58 2013 +0000 123792: complete annotations on text ranges feature but underlying problem was always there ready to trigger. For this case only render the full page if the state of comments scrollbars *toggles*, i.e. if there wasn't scrollbars and there ends up still with no scrollbars avoid the (bad) hack of invalidating the page Change-Id: Ic7fd432d2317b0f5ad8d8773636f99fe75d660d6 :040000 040000 341fa47a9c9903df1703affe37d37623e1408573 347f06192738989dc3b7d52cffefa7eb8f684cdf M opt https://cgit.freedesktop.org/libreoffice/core/commit/?id=378c74ce290ab772f962db51ff8cba200cb40144
Adding CC to Caolán McNamara Bibisect done based on comment 42 Related to regression.. this commit in question made the likely pre-existing problem more visible, I guess.
re comment #44, yeah probably makes a preexisting problem more visible under certain conditions. Less complete invalidates forcing complete redraws could make something underlying more obvious seeing as there would be less papering it over. comment #43 is a case that can only happen with comments in the margins so original report in comment #1 that doesn't have any of those would remain unchanged even with those extra invalidates added back. Is there any examples of this *not* under windows, i.e. is there evidence it is cross-platform or windows-specific ?
(In reply to Telesto from comment #42) > Created attachment 169357 [details] > Example file > > 1. Open the attached file > 2. CTRL+A > 3. CTRL+X > 4. CTRL+V > 4. Scroll up > 5. Triple click "pour at the top of the page" > 6. Nothing happening -> File reload -> Possible shift visible (not sure) > 7. If not repeat 2-6 2 times.. it should have happened by now I did not notice any text tearing with the document you attached either; however, your document is in read mode only. I wonder if that is significant because if it is only related to documents being edited.... Also, your document is just over one page in length, and I have only noticed this issue when the documents are at least three pages in length.
Created attachment 169369 [details] Screencast
(In reply to Caolán McNamara from comment #45) > Is there any examples of this *not* under windows, i.e. is there evidence it > is cross-platform or windows-specific ? Cross platform.. I bibisected it against GEN (bibisect-50max). Also seen under GTK3 with 7.2 and Windows Skia. And have seen it on macOS too.. I think I remember it seeing in 4.3 too (but pretty long time ago). Tried back in the day to pit down.. but couldn't figure out working steps. You need to have a good eye and sometimes try and error (see screencast) But the bibisect did go pretty well (and is in the area where I expected it to be)
Created attachment 169370 [details] Close-up of previous screencast..skipping 5 seconds each time
Significant new clues on the text tearing issue when scrolling or editing text: • It does not seem to occur with the zoom factor set to ≤100% (with or without the sidebar displayed). • It does randomly occur with the zoom factor set to >100% (with or without the sidebar displayed). • It does occur with the zoom factor set to Fit Width (156% with the sidebar hidden, or 117% with the sidebar displayed). The former is my usual, preferred setting, as per all my previous postings on this issue. • It does occur, albeit far less frequently and far less dramatically, with the zoom factor set to Optimal (197% with hidden sidebar), but it also does not seem to occur under those conditions with the sidebar displayed (148%). The last three points are curious. Why would enlarging the workspace to Fit Width (156% with the sidebar hidden, or 117% with the sidebar displayed) cause the issue but using the Optimal setting (197% with the sidebar hidden, or 148% with the sidebar displayed) seem not cause it? Verified previous means of manifesting the problem: • It can be replicated most easily by using the scroll up/down buttons, although it also does it using the scroll bar grab handle, the mouse scroll wheel, and/or the laptop touch pad. Verified means of correcting the torn text problem (not a fix, a band-aid): • It can be made to correct itself by clicking on either the Toggle Automatic Spell Checking or Toggle Formatting Marks buttons, Reloading the page, scrolling the page up/down until the damaged text is off-screen, or by Viewing the sidebar if it was previously hidden. Means of seemingly limiting the frequency and severity of the issue (not a fix, a band-aid): • Do not use the default templates in the United States because the templates use A4 paper instead of the correct Letter size (8½ ʺ×11ʺ). This was another reported bug that has yet to be addressed. • Do not use the Page Format Margins setting of Normal (0.75ʺ) because the right margin is inexplicably set to 0.79ʺ instead of 0.75ʺ. This bug was reported as part of the aforementioned one about the Letter size issue. • Increase the font size above 10 point. • Increase the line spacing beyond the preset single or 1.15 settings (prefer using the Fixed Custom Line Spacing to be at least 2 pts > the font size). • Do not use the bizarre, non-integer default Heading sizes (e.g., Heading1 of 18.2 pt and Heading2 of 16.1 pt). Instead, use integer (non-fractional) font sizes and line spacing. • Do not use Smooth Scroll as it operates opposite of what’s indicated by the checkbox. This was 100% repeatable under the circumstances I indicated in yet another bug report, but it was dismissed as unverifiable. In this case, it seems to have a minor affect on the text tearing as well, as without it the problem seems to occurred less frequently and produces far less distortion of the characters. So, the overall analysis seems to be that the larger the zoom setting, the worse the problem gets—except most notably when using the Optimal setting. It may be that the problem exists with negative zoom increments, but it’s simply too hard to see. Also, the larger the font size and line spacing the less frequent and severe the issue seems to be. Other factors, as outlined in the bullet list directly above, may also play some role in the occurrence and repeatability of the issue.
Commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c and comment https://cgit.freedesktop.org/libreoffice/core/commit/?id=6db39dbd7378351f6476f6db25eb7110c9cfb291 appears to relevant for bug 140101. And might be cause of this too.
This may be it! I know I’ve said this before, but the problem with troubleshooting a system as large and complex as LibreOffice Writer is that it has so many interconnected features (some necessary, some just bells and whistles) that it makes seeing the forest for the trees extremely difficult, especially for a newcomer to the product like myself. I now suspect that the cause of the text tearing issue is two-fold, one relating to a feature of the product I did not like at all upon first using the product—that being the sidebar, and the other regarding a feature that I wrote a bug report on earlier—that being the fact that the so‑called Smooth Scroll feature works exactly opposite of what the name implies (which is to say that by selecting that checkbox the text scrolls in a somewhat jerky manner and deselecting it makes for somewhat smoother scrolling). How I came to this conclusion. A replier to this thread attached a read-only document that did not exhibit the text tearing issue. Another replier, or perhaps the same one, mentioned earlier that he wrote either the help or user guides for LibreOffice and verified that the text tearing issue happened all the time and noticed that the problem only seemed to occur after editing a document. So, what I did last night was first spend an hour playing with one long, heavily formatted document that I could get to exhibit the text tearing problem quite frequently by using the up/down vertical scroll bars buttons. I then selected the so-called Smooth Scroll option, and that combination made the document exhibit the text tearing issue 100% of the time (you might have to scroll, stop, scroll some more before noticing the problem, but it was 100% repeatable at some point scrolling through the document). It did not make any difference if I did any editing or not, whether I had the sidebar displayed or not (although I had it open and was using it earlier), or what the zoom factor was (as long as it was over 100% (see earlier comment about Optimal view). I then hid the sidebar, closed the document, and finally closed Writer. I then immediately re‑opened Writer and the document I had been using. I spent the next two hours scrolling every which way (scroll bar up/down arrows, scroll bar handle, mouse wheel, and touch pad) and never once had a repeat of the text tearing—not even minimal tearing. This morning I spent another couple hours to verify my findings. As long as I never open the sidebar and did not select the so-called Smooth Scroll feature, no problem. However, if I did turn on the Smooth Scroll, I noticed that although I never observed any perceptible text tearing, what I did notice was that when I clicked on the Toggle Automatic Spell Checking that there would, on occasion, be a noticeable redrawing of the page, albeit ever so slight (changing the line spacing and/or text size just enough to see an overall shift in the line placements on the page, whereas with the Smooth Scroll option deselected, this does not seem to ever happen (the display is rock solid), although that could simply be due to it being an extremely rare occurrence). I did, however, notice some text tearing (on very rare occasions) on the line immediately above the highlighted word I was going to edit, but considering how much worse and repeatable the text tearing issue became, especially in combination with using the sidebar, I think it is definitely worth pursuing. So, the culprit seems to be two-fold, with the factors being the sidebar with an assist from the Smooth Scroll feature (I still have no idea why anyone would ever want the scrolling not to be smooth, but I am grateful in this case that I can turn it off to get the product to work as expected…or at least to approach that goal). So, this is about as far as I can go with this. I've spent countless hours narrowing this down, complicated by the steep learning curve of getting familiar with LibreOffice Writer. It’s now up to an experienced programmer to delve into this and hopefully fix it.
The text tearing issue is worse than I originally thought, as that minor blurring, tearing, or skewing of text seems to cause eye strain (in much the same way you get headaches and feel inexplicably fatigued when you need glasses because things are slightly out-of-focus). In my case, I have been having occasional, sharp, stabbing eye pain in either eye or, more often, long-term “eye-ache”. This might not be due so much to the actual problem as it is the constant scrolling of text to try to narrow down the cause of the problem causing a vertigo-type reaction. In either case, my terrible eye-pains have gone away after a week of not using LibreOffice Writer. Additionally, I may have observed an occurrence of the text tearing issue with LibreOffice Calc, but I was too fast on the mouse button and had already selected another page after that momentary glimpse of the tearing. Also, I happened upon a government PDF file that looks as if it were composed using LibreOffice Writer because I saw what looked to be the same tearing issue. Interesting that none of the web pages that I copied into word processor documents seem to ever exhibit the text tearing issue. The text portion of these webpages are in the Normal (Web) style, but that is apparently not a style option to select from with LibreOffice Writer.
Created attachment 169951 [details] Text tearing in LO Impress during slide animation transistions
Comment on attachment 169951 [details] Text tearing in LO Impress during slide animation transistions The text tearing issue also seems to exhibit in LibreOffice Impress, as seen, for example, in the transition between slides that involve animation in the attached file, Electricfields Presentation. The text will appear blurry and double-struck (giving the illusion of being boldface, albeit only temporarily). Oddly enough, I have other files from different sources where the animated slides do NOT exhibit this problem.
As indicated in earlier posted comments to this bug report, the text tearing issue seems to be an issue when the zoom factor is greater than 100%; e.g., when you choose the “Fit width” option (with no sidebars, that’s 156%). However, I think I discovered something very interesting, which is that if the zoom factor is larger than that (in the Normal View), large enough so the right side of the page is off-screen (which is to say to the point the horizontal scroll bar appears), it does NOT appear to exhibit the text tearing!? Not only that, but there is not the tell-tale sign of the lines of text slightly readjusting their height when selecting Toggle Automatic Spell Checking (Shift + F7), which always puzzled me because I see no reason for the text height to be changing. Also, if you select Web View, it does NOT appear to exhibit the text tearing (or height shifting) either!? I suspect this could be a truly significant clue to the origins of the issue.
With regards to my previous comment,zooming the text to something over several hundred percent is obviously not a viable workaround because you would have to continually scroll back and forth horizontally to read the text. It seems that I may have stumbled upon another interesting clue/temporary fix, one that seems to work without blowing the page up to those huge percentages, which is to choose a Zoom Factor of Optimal and a View Layout of Automatic (instead of the default Single page). This seems to work with or without the sidebar displayed.
One more interesting tidbit I discovered this morning (in reference to my previous comment). In addition to the selections mentioned (Zoom Factor set to Optimal and View Layout set to Automatic), it turns out those only work if you do NOT have smooth scrolling selected.
(In reply to Caolán McNamara from comment #45) > Is there any examples of this *not* under windows, i.e. is there evidence it > is cross-platform or windows-specific ? Bug 149322 makes it cross-platform, IMHO.
The related Bug 149322 was recently fixed (for LibreOffice 7.4.4 and 7.5). Could you please test to see if you can still see the issue you describe, using a recent development build available here: https://dev-builds.libreoffice.org/daily/master/current.html Thank you!
Dear Bob, 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: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO 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! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Bob, 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 Warm Regards, QA Team MassPing-NeedInfo-FollowUp