Created attachment 60225 [details] image of corruption in headings display Upon loading the document, there is display corruption of the header sections of the document. Sometimes they display correctly, sometimes they load up all strange with the text split over several lines. The corruption is sometimes out of order letters, text spread out over multiple lines with some letters invisible, and sometimes the line of text is just completely invisible. It happens independent of font type. If you reload the document, the corruption will sometimes go away or it will be different. If you close out all instances of LibO, it will usually load better the next time. If the corruption is not present at load time, it doesn't appear during editting. If it is present, I don't think it goes away while editing. One document can be fine, and the next you open is affected. The data in the file is correct and not altered, so not a data corruption issue. IF you remove the formatting from the text, it immediately appears correctly. This is using a document created solely in LibO, so no issues with import formatting or any of that. It has been happening from at least 3.4.x (whenever the graphite2 stuff was put in) through 3.5.2. It never happened that I can remember on 3.3 or on OpenOffice.
Created attachment 60226 [details] second image of headings corruption this 2nd version was after closing the document after previous screenshot and then reopening.
I should also note, that is has happened to me, even after doing a complete uninstall (user data as well) and reinstall (3.4.x, and 3.5).
it also seems to happen more frequently after opening and closing multiple documents.
I do not reproduce the problem with my own documents. Could you attach the document having this problem, as screencopies do not allow to make tests? Best regards. JBF
Created attachment 60596 [details] Document that often has the corruption As I said in my other comments, the document doesn't always show the corruption. Sometimes it does, and most of the time it doesn't. And I checking into the XML and the textual data is still there, so it's more of a rendering issue than a data corruption issue. I've had it happen on even extremely simple files with just heading elements in it as well.
Are you really using this file under MS-Windows ? If it is the case, you should check if you Ubuntu font is installed on your PC. Indeed the heading styles of your bugdoc are defined with Ubuntu font and this font is probably not installed by default on MS-Windows systems. Best regards. JBF
If you would look at the image files, you see that the font is indeed installed. And I've had it happen using just the default settings of Times New Roman and Arial for Headings. Also, I was typing a clean, new document on my netbook (Win 7, LO 3.5.2), and the same thing happened on a different computer. So, there is definitely a bug. Now, I doubt it will be easy to find, as it's probably in Graphite2 (if I got the rendering library correct) or a memleak/garbage writer. There are also other display bugs like sometimes a line in the display will get compressed maybe like 70% of it's full height.
@Jon Grossart: A simple question, just in order to prevent misunderstandings: When I look at the screenshots, I get the impression that the *headline* display is corrupted, not the (page) header/footer display. Is this correct, i.e., by "headers in document" you mean the headlines and subheads, not the page header? Thank you!
(In reply to comment #8) > @Jon Grossart: > A simple question, just in order to prevent misunderstandings: When I look at > the screenshots, I get the impression that the *headline* display is corrupted, > not the (page) header/footer display. Is this correct, i.e., by "headers in > document" you mean the headlines and subheads, not the page header? Thank you! Yes, I mean "Headings" in the document. I should have said that instead of header. The header/footer are fine/unused.
I remembered another important point. If the corruption has happened and you export to PDF, it is present in the PDF as well. If the display is correct and you export, the export is correct. So, the bug would probably be somewhere in the representation of the display, rather than the display code itself. Also, I had a similar corruption happen yesterday -- in the actual header and without headings. I had updated the template for my business header. I went to open up a document with an old version of that template. If I choose to leave styles alone, it loads correctly. If I choose to update the styles, it creates the "stair step" display seen in the other one. It did it several times in a row. Today, after a full reboot, it's working correctly. Stupid intermittent bug.
I should also add I've seen corruption where it misorders the text: "Title" became "iTtle". You can see that report at https://bugs.freedesktop.org/show_bug.cgi?id=46548#c4. I haven't seen that one yet in LO3.5.2.
Created attachment 60984 [details] Picture of Alternate type of heading corruption Note that some of the letters are even off of the page.
Created attachment 60985 [details] Blank ODT file with some formatting imported
Created attachment 60986 [details] Notes to copy into blank template
I finally got the 2nd type of corruption again, and it does seem only related to headings. Steps: 1. converted old .docx file in MS Office 2007 to .odt (via MSO 2007) 2. opened up blank notes file that had some imported formatting 3. opened up converted .odt and copy contents into blank document with correct formatting 4. view corruption -- it happened several times, even with closing and reopening LO completely. However, this time, the PDF that I generated was correct. The "e" handing off the page in one of the attempts at opening the file actually scrolled with the page rather than being attached to it's initial position. I'll attached the saved file of the corruption from two different attempts that both showed corruption.
Created attachment 60992 [details] Saved Contents of Corrupted copy-paste Attempt 1
Created attachment 60993 [details] Saved Contents of Corrupted copy-paste Attempt 2
happening less frequently on 3.5.3, but still happening. I've also noticed a different type of display issue. After typing for a while, the header styles also won't apply correctly. For example, my headings are bolded. When I select the heading style, the font type, size, and color get applied, but often the bolding won't. I can reopen the document, and sometimes it will or won't show up. I can reset the heading to "default" and then back to "Heading" and it will sometimes work.
Is there any more info needed before you change the status to an actual bug?
still present in 3.5.4
(In reply to comment #19) > Is there any more info needed before you change the status to an actual bug? @Jon Grossart: No, no more info from you is needed -- thank you very much for all the input! What we still need is someone who can reproduce the bug step by step and independently. As far as I can see such confirmation is still missing. Therefore I change the Status to UNCONFIRMED (as appropriate) ... I will try to reproduce this issue myself in some days (I'm not at home in these days) and report any findings. [If I forget to do so, please remind me by a personal mail ;-) There are just too many bugs, and it is easy to oversee one, sorry!] But it would be even better if someone else who works on a Windows machine could try to reproduce this issue (I am on MacOS, and this bug may well be somewhat platform-related).
I've had it happen on 3 different Windows computers, so it's more than just one computer. And on multiple documents. It also only seems to be problem with some combination of bigger documents, lots of opening/closing document, and/or longer editing sessions.
@Rainer Bielefeld: This is a very interesting bug; but until now, I could not reproduce it on MacOS X, so this issue may be Windows-only. Could you, as a very experienced LibreOffice on Windows user, please take a look at it? You will also know which extra information from the original reporter could be helpful to track this down. Be warned that it is not easy to reproduce this issue; it might take some extra afford (or whatever is the English word for "Aufwand" ;-) to reproduce it; but nevertheless we should take an eye on it, because IMHO it is a rather serious issue, even if only reproducible from time to time ... Thank you very much!
I've had it happen in 3.6.0 as well (I was hoping it would be fixed). I haven't seen it in 3.6.1 yet, but haven't done much editing lately.
Sad day...just had it happen on 3.6.2.2 It seems to happen less often, but definitely still happening.
@ Jon Grossart: I am very sorry that this issue is still unconfirmed! I have tried several times to reproduce it, but I never succeeded, maybe because I am on Mac OS X (and it is possible that this is a Windows-only issue). Now I have written to the QA mailing list, asking for help about this issue; I hope someone else will be able to reproduce it.
Created attachment 68432 [details] Correct display I cannot reproduce this bug. The view of the font name in the screen, does not mean that it is installed on the system. Can you select it in the font selection list?. See the attached screenshot, and I have not installed the Ubuntu font. To verify that it is in the system, make sure it is in C:\Windows\Fonts.
Checked with: LO 3.5.6.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce with attachment 60225 [details]. Loaded few times without any issues. (In reply to comment #22) > I've had it happen on 3 different Windows computers, so it's more than just > one computer. And on multiple documents. > It also only seems to be problem with some combination of bigger documents, > lots of opening/closing document, and/or longer editing sessions. As you can reproduce it at will on different systems please describe step by step what you are doing. More details, the better. Every key press and every mouse click counts. Attach more affected files if possible. Unfortunately this bug won't be fixed without reproducible testcase. Also additional information would be helpful: - PC configuration (hardware and software details like gfx drivers) - OS details - LibO localization (UI language, Locale setting) - LibO configuration (addons or not default settings)
Created attachment 68439 [details] terminal session with valgrind output At line 1554 LO displayed the documentwithout obvious rendering problems. I scrolled down several times, taking the typescript to 1552 lines. Then I closed the program. I hope thie valgrind output is helpful; I do not not know enough to use it. Terry.
So, it happens on a Core2Duo (self-built, AMD 6750 video card, 64-bit OS) and Samsung NC10 (GMA945, 32-bit OS). Both are running Win 7 Ultimate. LibO is just standard install (only installing Eng-US and other English locales). It does not happen at will (thankfully, or unthankfully for debugging). I do have the Ubuntu font installed on my computer (yes, in Windows), so it does display correctly. I does only seem to be a Windows problem, as I've tried to recreate it VMs of Ubuntu and it never has done it. The documents are usually 6-18 pages long and consist of long sets of bulleted/numbered lists. It tends to happen after opening/closing multiple similar documents, especially in parallel. Lots of copy and pasting. Once it happens, it tends to keep happening until I completely close out LO and then reopen it. Hence leading my to believe it's some sort of memory leak/bad pointer/garbage writer and not a clean/quick bug. It rarely (dare I say almost never on the newer releases) happens on first loads. It does tend to be after longer editing session. It did not happen before 3.5 (never happened once in 3.4 or earlier), and has been happening since. It's persisted on both computers even with completely clean install of LO (remove user directory and start fresh). Is there anything I can run on my install once it's in that state to gather any debug info?
> It did not happen before 3.5 (never happened once in 3.4 or earlier), and > has been happening since. It's persisted on both computers even with > completely clean install of LO (remove user directory and start fresh). > I misspoke as this has been going on for so long -- it never happened in 3.3 or earlier (OO.org before that). It started in 3.4 and has been getting less frequent, but still happens. I should also state for installation that I don't install the quickstarter, and I start the process either from the LibreOffice "generic" icon or from a direct opening of a document.
Opened up some of the documents on 3.6.4 on my netbook and had the problem happen yet again. So, two different systems show the same problem.
Still happening in 4.0.3.3
I should also say, I can provide my whole suite of documents in someone is serious about testing the bug. I'm not posting them to the bug, because they do contain some personal information/proprietary info, so I don't want them being "public". Main situation is still the same. Open up a document, edit document, save (and potentially close the document but no the program), repeat for new document. I will usually happen after a few minutes up to a few hours. For example, just starting editing these documents again, and it happened after 4 documents, doing only a few minor edits per document. And it's not tied to the Ubuntu font. I've had it happen on headings using just the default fonts. However, the documents it's happened in always have lots of bullets/numberings.
I just wanted to summarize the issue: - happens on Windows (not to say it can't happen in Linux, but I don't play with my documents in Linux at all other than for a few tests) - If I remember correctly, it started with the release that integrated graphite2 for rendering (not 100% sure about that) - corruption is only with the headers - Once the corruption happens, reloading the same document tends to keep the corruption. If I completely close out LibO and reload the document, the corruption is usually fixed - it is not a data corruption issue. The base .odt file is fine. Saving the file even if the visual corruption is present still saves the correct data in the file (thankfully :) ) - if the visual corruption is present, exporting to a PDF will still show the same corruption. This would tell me that is not directly with the "output" of the data, but probably in the visual representation of the data. - happens after a variable time -- sometime not at all, sometime on loading my first file. It usually happens after loading a few files, editing them (sometime only minor edits), saving them, and going to the next file. - files that it happens on are based on a template with changed page margins with 2 imported styles (one custom bullet, one custom numbering) and custom header styling (color, font). The documents contain numerous and long lists of both types (mostly bullets) - I've had the corruption with just using the standard font setup - it's happened on 2 separate computers (32-bit and 64-bit) using multiple versions of LibO (including complete clean installs with deleting the user directory)
uninstall 4.0.4, install 4.1.0 (keeping user directory) Still having display corruptions. However, I don't seem to get the "jumbled" headings as much (maybe at all). The corruption has taken to be more invisible headers. Formatting is still there, but the text is transparent.
just got the first jumbled heading on 4.1.0, so still in full effect
> it never happened in 3.3 or earlier (OO.org before that). > It started in 3.4 and has been getting less > frequent, but still happens. so I'm updating version field to "3.4 all versions". not reproducible on my 4.1.1 final release under Win7 64bit (but I know it's an hard to reproduce bug). have you tried upgrading to 4.1.1? do you still see this? and how frequent it is? once in a week? every day? does it happen just with .odt or even with .doc? what about graphic cards? do your computers have the same card or not?
Can't reproduce with LO 4.1.1.2 or 4.2 on OS X 10.8.4.
(In reply to comment #38) > > it never happened in 3.3 or earlier (OO.org before that). > > It started in 3.4 and has been getting less > > frequent, but still happens. > > so I'm updating version field to "3.4 all versions". > not reproducible on my 4.1.1 final release under Win7 64bit (but I know it's > an hard to reproduce bug). > > have you tried upgrading to 4.1.1? do you still see this? and how frequent > it is? once in a week? every day? does it happen just with .odt or even with > .doc? > > what about graphic cards? do your computers have the same card or not? If you look at the earlier comments, it's listed on the computers I've seen it with. 2 different AMD cards (same computer) and with Intel GMA 945 (Atom netbook) and on Intel HD (don't remember which one, core i3 based from a few years ago -- maybe HD 3000). It's happened up through 4.1.0. I haven't seen it on 4.1.1, but I also have worked on those documents since then. It happens consistantly, but not reliably. It's only using .odt files. Since these documents are the only ones I've seen it on, I have a feeling it has to do with the amount of ordered lists I'm using. It's basically pages of lists. It rarely shows up on a cold start of the program. It usually happens after opening and closing several documents and working on them in one instance of the program. If I just open and close and repeat, it doesn't seem to happen. It happens more when there has been actual time open in the program as well editing and saving.
(In reply to comment #39) > Can't reproduce with LO 4.1.1.2 or 4.2 on OS X 10.8.4. I haven't seen it happen in the little bit I've played with these docs in Ubuntu either. I have a feeling it's a Windows specific bug, which most of the developers don't use. As I've also said, it doesn't affect the data itself, only the on-screen representation and any exported PDF once it happens.
Ok. Ping us if the bug comes back in 4.1.1 (hopefully not).
(In reply to comment #42) > Ok. Ping us if the bug comes back in 4.1.1 (hopefully not). In a bug that has been around from 3.4 - 4.1.0, I'd be surprised if the relatively small amount of changes in 4.1.1 would have an impact. I will update though, if I see it specifically.
@Jon any news? bug still round here in 4.1.3 or RESOLVED WFM?
No news. I don't need to edit the files that show the problem all that often, and haven't done so in 4.1.3. So, it may be fixed, but since it's been around for 1.5 years, I'd be very surprised if a .x.1 fix did anything about it with a known root cause.
ok I move this to NEEDINFO. reopen if when you will be 100% sure that the bug is still present or is gone.
Nope, still happening on 4.1.3.2. Just got back to editing some files that needed it. Attaching another screencap.
Created attachment 89796 [details] LibO 4.1.3.2 Failure
Created attachment 89803 [details] Correct PDF Output from a file
Created attachment 89804 [details] Corrupted Exported PDF of Same file When the visual display happens, the corrupted version can be output to a PDF.
And apparently, having non-printing characters on and inserting manual page breaks causes it to happen more often, it seems.
This bug really could use a summary treatment as per: https://bugs.freedesktop.org/show_bug.cgi?id=73993
(In reply to comment #52) > This bug really could use a summary treatment as per: > https://bugs.freedesktop.org/show_bug.cgi?id=73993 The main bug report is still the same summary, as no one has really put much here but myself. I will make new summary though, to follow the procedure.
Still happening in 4.2.2.1
Summary as of 2014-3-25: Corruption - display of the headers gets jumbled -- will get split on multiple lines with characters often missing or jumbled out of order, sometimes the header is just invisible (but the header styling is always present) - DOES NOT CORRUPT the underlying data (verified by reloading and by checking the actual contents in the ODT file's XML) - once it happens, opening and reclosing the document will keep the corruption - once it happens, opening up additional documents tends to tend to also show the corruption - once it happens, opening and closing LibO will almost always fix the issue - happens "randomly" -- it can be on the first document, or not happen for hours - tends to happen more if there are lots of opening and closing of documents in the same LibO instance - also tends to happen if changing something that requires re-displaying the whole document (like changing the page setup, importing styles, inserting manual page breaks, turning on non-printing characters, etc) - if you export to PDF, the same corruption that is seen onscreen is seen in the PDF (which tells me that the bug is somewhere in the internal representation of the document's data) Documents - happens on multiple documents - all documents are based on the same template and have the same ordered/unordered list styles - documents are basically long sections of lists (ordered and unordered) divided into sections - I have VERY rarely had it happen on a normal document (i.e., without the huge number of lists), but I did get it happen once (at most a very few times). Versions - happens on 3.4/3.5 (at least 3.5, don't really remember if 3.4 at this point) up to 4.2.2.1 (I believe it starting happening in the release that rolled out the graphite2 rendering code) - some versions have it happen more than others (not sure enough to make it a trend, per se, but only from a subjective experience) -- however, it's happened on EVERY release since it started happening 2 years ago (I always move to the n+1.0.0 release when it comes out) - happens even on a clean install of a version (removing the whole user directory as well as a previous uninstall) Computers - happens on multiple Windows computers (Win 7 64 bit desktop, Win 7 32 bit netbook, Win 7 64-bit laptop) -- different video cards -- desktop has AMD 69xx and laptops have intel 945GM and intel HD 3000 - for the desktop, happens across multiple driver versions - I've tried to reproduce on linux (Ubuntu and openSUSE) and have not been able to, but I have not spend nearly as much time in the documents there - all computers have the appropriate fonts installed - computers have been checked for memory errors and there are no other odd issues happening Status of Work on Bug - there hasn't been any - some people question my document -- yes, it uses Ubuntu font, and yes, it's installed on my system - a few people have tried to reproduce (1 in OS X and 2 in Windows), but had no success (of course, since it usually doesn't show up for awhile or unless you're doing a lot of changes to the document, just opening and closing it a few times won't usually show it)
@Jon could you please give an update of the bug status with current LibO 4.3.2.2 release? has anything changed?
Hi Jon, Did you try to change all fractional font sizes by integer size values? Best regards. JBF
@tommy27 -- I haven't edited these documents in awhile, so I haven't had the direct chance to check it out. I'm about to start doing some editing again, so will be update to update that. @Jean-Baptiste Faure I have not tried setting the fractional fonts to full size. I will try that when it fails next. Although, I didn't manually set those -- I just used the % of size option. And it usually works. Will update as I find out more.
I did just have it happen again in 4.3.4.1 (Build ID: bc356b2f991740509f321d70e4512a6a54c5f243). So, sadly, still an issue. This time it happened when I overwrote the text styles in the document with the ones from the formatting document that I use. If I went into the styles for the heading and it was set to 115% (which ends up at a fraction value). If I just change that value (still a %) and do apply, it corrects the drawing or the headers. If I then go back to 115% and apply, the dispaly is still correct. I went to reload the styles again from the base document again, and it again corrupted the display. It's more than the other text issues like vertically cropped lines that just needs a redraw. It's definitely some issue in the data structures since it persists in a PDF output. Reloading the document and then redoing the procedure resulted in the correct display initially.
Happened in 4.4.0.3. I will switch to the new openGL render and see if I can get it to happen again.
I had it happen with use openGL rendering checked. I'm not sure how to make sure it was actually running in that mode though, and not being blacklisted. I created a master document of many of my files, and it was able to cause the problem much more often than any single document. If any dev really wants to look into it, I'd be happy to provide it to them, but I won't put it in the public bug report.
I've had it happen for the first time in normal text as well. Using master documents of my documents (which involves many, many bulleted/numbered sections), it happens very frequently right now in 4.4.0.3.
Huzzah -- I've finally had it happen in a basically clean W8.1 VM -- which I've got in a saved state. How can I debug what's going on? I've now seen it in two distinct types as well (real and in VM): 1) headings are jumbled or some text invisible on the same line -- changes depending on zoom level and sometimes is completely present, change zoom, and it's gone again -- any of the jumbled text is not output on PDF export 2) headings are jumbled across multiple lines -- persists across redraws, persists in PDF export. I currently have #2 in the VM saved state. I've also tried it using the % based font setting and using pure full pt settings for the headings. I've had it happen in both. So, now I've had it on real hardware (AMD, Intel), 3 different computers, % fonts and full pt fonts. I also just did a full memtest of my ram to make sure it wasn't corrupt memory or something. I think it's safe to say it's a real bug.
Hi Jon, Thanks for your patient and detailed reporting here. Since you describe that it happens irregularly and after, let me say, heavy work, and that others (including me) are not able to reproduce the problem, it looks as in interaction between your document (maybe some unidentified element) and the systems resources? Then, seeing the unlikeliness of this going to be changed other then with general improvements maybe, it's better to set this as WorksForMe of NotOurBug, or..? Maybe it does not look friendly, but at least it stops spending resources on a unknown target. Would love to read you opinion on this. Cor
Created attachment 115285 [details] Firefox on Ubuntu showing similar problem So working on Ubuntu to, coincidentally I see a similar problem, in Firefox..
Alternatively if you have a VM that is available, and steps to reproduce the bug on there, it does offer a nice opportunity for developers to look at it.
(In reply to Cor Nouws from comment #65) > So working on Ubuntu to, coincidentally I see a similar problem, in Firefox.. Sorry, not the same problem!
(In reply to Cor Nouws from comment #64) > Hi Jon, > > Thanks for your patient and detailed reporting here. > Since you describe that it happens irregularly and after, let me say, heavy > work, and that others (including me) are not able to reproduce the problem, > it looks as in interaction between your document (maybe some unidentified > element) and the systems resources? Then, seeing the unlikeliness of this > going to be changed other then with general improvements maybe, it's better > to set this as WorksForMe of NotOurBug, or..? > Maybe it does not look friendly, but at least it stops spending resources on > a unknown target. > Would love to read you opinion on this. > Cor Honestly, even though it's an odd bug, I do think it's a real bug, and not just something for me. If it was just a visual bug that could be fixed with a refresh, I'd care less about it, but when it persists through PDF export, something is definitely going awry. I've had it happen for so long, across multiple OSs (all windows) on multiple computers and graphics card vendors, so many versions of LibO, that there is something definitely going on. Plus, it can happen the first load of the document in a fresh instance of LibO. And I have had it happen in a document not of these ones I'm working on (but much more rarely). And as I said in other recent reports, on 4.4.0, it happens more easily. I think a big part of the problem is so few developers testing on Windows (from what I've read). Plus, having it happen in the VM removes the issues about it being tied just to my devices (with the exception of RAM, but I've tested that repeatedly). I know it's a weird, hard to track bug, but it's definitely a bug somewhere. And regarding the VM, it's still in the state waiting for a dev to have the interest to debug it or even tell me more to look at. The only debugging instruction for windows is for crashes, which this isn't. As it's a 32 GB VM, I'm not really going to upload it anywhere. But it's just a VirtualBox instance with guest additions, Windows 8.1 installed with LibO. It's nothing complex. I can provide the full document set to an interested dev, but I won't upload it to the bugtracker for privacy reasons.
(In reply to Jon Grossart from comment #68) > Honestly, even though it's an odd bug, I do think it's a real bug, and not > just something for me. Sorry, but I missed that up until now. > And regarding the VM, it's still in the state waiting for a dev to have the > interest to debug it or even tell me more to look at. The only debugging > instruction for windows is for crashes, which this isn't. If you are interested to try yourself, please go to irc and start to bite the bullet. But if development is new to you, it's a huge one to swallow ;)
Created attachment 117475 [details] screenshot of corruption 4.4.4.3
Created attachment 117476 [details] pdf of corruption 4.4.4.3
@Gordo does this mean you were able to reproduce it? if yes can you tell how?
I installed Ubuntu font. Then I took Notes Template.odt and saved it as a template with the name "Default ODT 0.5" to match the template in the properties of "1 General VM5". I opened the template up to edit and had the other document open. One thing that stands out to me is the character style of the bullets. The paragraph style font is 11 and the bullet size is 12. If you place the cursor at the end of one of the bulleted paragraphs and add something (a space) you will notice that the line is shifted. Do that to enough of them and some lines will be forced onto the next page. After saving and reloading the lines are back on the previous page. Another way to see the shifting is to select the bullets to get the grey shading. Anyway, after multiple saves and updating styles and leaving everything alone for quite some time, the corruption reared its ugly head. I have no idea if I will be able to reproduce it. Also, the borders of the headings are set to merge with next paragraph. Maybe they feel the inexorable tug of the difference in bullet and paragraph font size. Version: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
so finally we have another user seeing that issue that Jon reported years ago. status NEW
Finally -- thanks Gordo. I've had it happen on any system I've tried, but glad to finally get it in my own VM and someone else's computer. I won't make the claim that there might not be some odd formatting values setup, but most of them came from whatever was the default template back when I started with these document (especially the bullets -- all I did was select different ones for each level, not changing any font value). I've had it happen with other fonts as well, so it's not just the Ubuntu one (which was a thought I had as well). If I load up a Master Document with ALL of my files (which ends up being like 600+ pages), I can get it happen fairly quickly now. What odd, is that it will only happen on certain style changes. If I change the font/size enough times, it will happen. Then I can change to something else as it will work. Then back and forth and it will keep happening. Reload the document, and it will be a different combo that breaks it.
best thing would be to create a minimal test case where the issue in constantly reproducible. this would help a lot in debugging and hopefully fixing
Here is a different kind of corruption where the headings disappear. Preconditions: Ubuntu font is installed. 1. Open file "1 General VM5.odt". 2. Navigator docked on left and page zoom is at 80% and Sidebar is closed. 3. Set zoom to Page Width (mine showed 111%). 4. View → Sidebar → Styles and Formatting. 5. Right click on first heading → Paragraph → Borders and Cancel. 6. Right click on second heading → Paragraph → Borders and Cancel. 7. Right click on third heading → Paragraph → Borders and Cancel. 8. Scroll the document up and down a few times and shake it all about. 9. Click on Styles and Formatting in Sidebar tab bar to hide it. Result: Some of the headings disappear. Sometimes it happens after step 8 and sometimes it happens after closing the Sidebar altogether. Or some variation of the above. If you switch windows between Writer and your browser to follow the instructions during some of the steps, especially 8 and 9, then it might not work. I deleted my profile and did this again with a clean profile just to be sure. Windows Vista 64 Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Migrating Whiteboard tags to Keywords: (needAdvice)
So, I've been back to editing those documents again, but I've since done a full reinstall of W10 (so, third version of Windows on these documents) and switched to the 64-bit version of LibO with the release of 5.0. There are two types of corruptions that I've seen (again, only with the headers): 1. corruption with the headers having missing letters and being broken across multiple lines 2. corruptions where the texts just gets jumbled and misplaced on the line (sometimes even being off of the actual visible page (like being placed on the gray area outside the document Since my upgrade, I haven't yet seen #1, but I now have a 100% reproducible case for #2. And thankfully, it's even happening in a short document based on the default template! Notes: 1) the corruption only happens on certain fonts 2) it's only a messed up spacing, but it has the same characteristics as the other types of corruption, mostly type #2 and it still gets output to the PDF 3) it does seems font type related (some fonts works correctly other's don't -- including Ubuntu, which is the one I've been having the trouble with). 4) windows only. The same file on Linux (openSUSE TW with 5.0.3) renders fine. 5) It's best seen in the non-printing characters which shows up messed up placement of the text relative to the spaces and end of paragraph. 6) this error is also present in the Default Style as well (which is a change from before) Since it seems like I could make the old one happen depending on the font used, it seems that the whole situation has something to do with the font rendering, maybe the kerning support. Fonts Tested: Working: Arial, Liberation Sans, Liberation Serif, Times New Roman, Noto Sans, Noto Serif, Segoe UI Not Working: Bitstream Vera Sans, Fontin, Genitum, Open Sans Light, PT Sans, PT Serif, Ubuntu, Verdana I've loaded the same fonts in NexuFont in Windows to show that the fonts themselves don't have trouble outside of LibO.
Created attachment 121208 [details] LibO 5.0.3 Windows Font Corruption
Created attachment 121209 [details] LibO 5.0.3 Font Corruption in PDF
Created attachment 121210 [details] LibO 5.0.3 JPG of Corruption
Created attachment 121211 [details] LibO 5.0.3 JPG of no corruption in Linux
Created attachment 121212 [details] Windows Fonts working correctly in NexusFont
Just an update, I've had it happen in 5.1.2 (64-bit) as well now. I've tried stressing the headers portion, and I haven't gotten it to happen. However, the interesting thing is that it's happens in normal body text now as well -- specifically the Sender and Addressee styles of an envelope. Still using the Ubuntu Font. The same thing happened several times -- multiple lines for the same text element with some letters missing. Another difference is that it is fixable just by doing a document reload, where before it would require a full LibO restart. So, the issues is still there at least, but it's characteristics have might have changed. I'm beginning to wonder if it's not more related to interactions with certain fonts.
'needsConfirmationAdvise' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]
Work on bug 71603 looks to have done some good here as well. Can not reproduce with STR in comment 77 Please test with master > 20161102, or the 5.3.0beta1 when released. =-ref-= http://cgit.freedesktop.org/libreoffice/core/commit/?id=03bff1b6b953e4b7a54d2fb7bbf366bea7e959d9 http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d39c2013374727b1c8f147b8b99d54402a7ff02
Just to add an update, I haven't been using the documents much, but it seems that the 5.3.x line with the switch to HarfBuzz for all platforms seems to have helped/resolved the issue. As I was suspecting, since it seemed not able to be reproduced in Linux, that it was an issue somewhere in the bowels of the Windows rendering code. I do need to be working in those documents again though, so if I don't see it come up again within a few months, I think I'll be be able to mark it RESOLVED then.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Well, even though the root cause of this bug was never found, it seems to have been resolved with the move to HarfBuzz for Windows. I haven't had it crop up since 5.3 on any document. So I'm marking it Resolved-WORKSFORME, and I will reopen if needed. Thanks for to the people who actually spent some time looking into it (esp. Gordo who was the only one who fiddled with it enough to actually reproduce it -- it's not easy to always do).
nice to hear that this "die hard" bug has finally gone.