Apache OpenOffice (AOO) Bugzilla – Issue 101122
Last line of a particular page cut horizontally on reload
Last modified: 2017-05-20 11:15:40 UTC
I'm actually running OOOm15 build 9379, but that wasn't on the above list. I have a book I've been writing in OOo for quite some time now. It was originally converted from text under 2.3.0 into .odt format, and I have recently upgraded to 3.0.1. Every once in a while, I will come to a page where the bottom line appears to be in a different frame from the rest of the page, only the line on the screen does not respond to the cursor, and if I insert lines to move the invisible line of text, it appears whole on the next page. I am attaching a screen shot that shows the problem clearly. The first time I ran into this (yesterday), I made some repeated combination of adding blank lines, deleting the paragraph break, and other changes that, somehow, made the funky line go away when I closed and reopened the document. I don't recall the exact series of steps I used, but they were farily lengthy and nothing changed at all until I closed the document and re-opened it. This time, I was not able to do this. I tried to reproduce the problem by copying the problem page and the following page to a new odt document, but even when I add the header and footer fields to the page format, the problem does not reappear, and the line spacing is different, even when I verify that the page format is the same. I _can_ work around this by copying the document to a new file and using the new file, which does not appear to have the same problem, even though I did the copy form the command line. In fact, if I rename the file, the problem disappears (which also means I don't have a copy with the problem any more, at least not in the same place, and that also means I could not have sent you a copy of it - foo). All I have left is the screen shot I attach. I am also attaching screen shots of the page formats between the copy with the problem and the copy without. I wish I could be more informative, but I really don't know how to reproduce this.... Hmm, seems there's no way to attach these, so I'm posting them on the above noted web page (which is not accessible from the main page, so please use the whole url).
Pls. attach a sample document (Using "Create a new attachment (proposed patch, testcase, etc.)" on this page)!
As previously stated, this won't work. Apparently, copying the document masks the problem (i.e., can't reproduce it). I am looking into some other issues in this regard that I have been seeing since 2.3.0, all of which relate to handling the last line on a page. If I can nail these down and reproduce them, I will send in everything I have on them. One example: Last line on page is blank if it begins a new paragraph (no orphans or widows specified) unless/until I manipulate the document to eliminate these. This may be related to handling 1.5 line spacing, which I routinely use, and large documents (200+ pages). This is part of the problem (hard to reproduce such a document). This also may be related to leaving a document open for a long time (>24 hrs), with numerous minimize/restore operations from day to day.
Feel free to reopen when you have a reproducible scenario and can attach a sample document.
Closed
Created attachment 61880 [details] Test data file that (should) contain the issue
I have attached a copy of the file with the data somewhat mangled. I can reproduce this bug on a 1680x1050 LCD screen (22") where the OOo window is stretched to cover the screen top to bottom (but not necessarily full screen width). In my copy, I saw the problem on pages 15 and 25, but you may have to look through for where you see it. I know this can be time consuming, but when you find it, you'll see what I mean. Please check every page until you find at least one with the problem.
I forgot to mention these: I'm running CentOS 5.3, x86_64, with the GNOME desktop using a single panel at the bottom of the screen. This may affect the artifacts. The exact dimensions of the window are 924x1026 pixels, with a 25 pixel top border, 2 pixel sides and a 3 pixel bottom. If the problem relates to the display size, this my help. I will attach a screen shot of the problem as well, so you can see what I see.
Created attachment 61896 [details] Screen shot of the problem
Also, this seems to happen most frequently on the first page of a chapter, where the spacing is different. These chapter headers are Heading 3 paragraph style, whereas the majority of the text is First Line Indent (you can see the details in the sample document I sent).
@mhrichter: sorry but this problem is globally (to many parameters: OS, resolution, specific document area in 400 pages) not reproducible. If this happens again: - press Ctrl+Shift+R to see if it not a repaint problem (problem would then disappear) - do "Tools - Update - Update all" to see if it's not a temporary reformatting problem. Further ideas: - see if a font change where the problem happens cures it. - try it on an other OS if you have the opportunity - change the zoom factor ... In any case try to isolate the problem to *a few* pages, where you can say: "this happens on page n°#" Also give the current 3.1rc2 a try. Feel free then to reopen. Every further effort to try to reproduce this in the current situation is from our point of view counterproductive and random. (I had a look at about 150 pages especially those starting with a new chapter -> not reproducible)
closed
FYI, this has not occurred in 3.1 so far (64 bit version, I think - I installed both), but there is another oddball problem I may report on later that is similar.
Okay, I'm able to duplicate this one, so I'm reopening it, with a copy of the original file and two screen shots. What I'm seeing changes between the "before" and "after" screenshots, where the "event" is when OOo completes loading the file. Until that point, the page looks normal, but the page number is wrong. After the file finishes loading, the page number is correct, but there's an extra text limit line that cuts off half of the bottom line. This is similar to the problem I reported in issue 102935, and I believe at this point that it relates to how the window is painted on the screen (note: NOT printed...). Revisions: This is from OOo version 3.1.0 (OOO310m11, build 9399). What I did to reproduce this problem using the copy file was just reopen it, but I was on page 24 at the bottom when it occurred, and I had just finished some minor edits in the original, but the problem also occurred in the copy with no edits, so I'm hoping you'll be able to see it, too. Please note: This is an unpublished edit of a previously copyrighted work, so please do not distribute, copy, etc., etc. except as needed to diagnose and hopefully fix this problem.
(groan) I don't know how I did this, but I added the attachments to issue 101998 by mistake - can you look at them there or should I re-attache them here (the document is 9+MB)? Mea culpa - dunno how I got the issue # so wrong....
Good news! Now I can reproduce it in a current DEV300m52 version on Vista! :) So system independent. The screenshot again: http://www.openoffice.org/nonav/issues/showattachment.cgi/63810/OOo-after.png The bugdoc attached in the wrong issue: http://www.openoffice.org/nonav/issues/showattachment.cgi/63808/ooo101998.odt Now my description to reproduce it for sure is different from yours, it seems: - Make sure you have Book Antiqua as font installed on the the system. (not sure it is THE big condition but it has certainly an influence on the layout) - Load bugdoc - scroll to page 24 -> everything is ok. - now open the Navigator - reload the document and very fast... - ...set the cursor in the page number field to jump to in the Navigator toolbar and press Enter. -> The last line of page 24 is cut as seen on the the screenshot. Notice: - It is not a simple repaint problem. Scrolling, doing Update All, zooming, even changing some fonts attributes on the last line doesn't cure the problem. - Even the Print Preview shows the effect. - More troubling, there is a gray line which cuts off this last line as a section boundary would force its display here...
I have two more clues: 1) This seems to be related to deleting enough on the first page of a chapter to change the content of the last line. This seems to happen mostly when the last line is not visible on the screen at the time, and the deletion shifts the off-screen portion of the document up. 2) I saw this a couple of times recently, including just now, so I went into the Format->Page and opened the Footer tab and set the "Space to text" value to 0, and the problem appears to be gone. This may be a symptom, not the problem itself, because I've never seen it persist for too long, and I've created PDFs from files with this issue that do not exhibit any funky-looking lines. Hope that helps.
There is a slim possibility that this is just a matter of extreme coordination, or lack thereof, on my part. I just had this happen again - I backed up one space and then attempted to back-select the next word. It failed twice in a row, so I did it more slowly, and this time it worked. I usually type really fast, so it could just be my clumsiness at high speeds - I will try to verify this (and not to look too stupid in the process...).
Please ignore my last comment here - that was for a different issue, and I must be too asleep to have noticed when the issue changed to this one.
I've noticed that if I reduce the Format->Page->Footer->Spacing by even as little as .02" (one increment), that seems to eliminate the problem, but only temporarily. I earlier tried adjusting the "Space before text" on the footer, which I now cannot find, and that seemed to solve the problem, but it has reared its ugly head again. I haven't tried increasing the spacing yet (didn't think of it), but I'll try that next time and see what happens.
On libreoffice atleast.
Reset assigne to the default "issues@openoffice.apache.org".