Issue 101122 - Last line of a particular page cut horizontally on reload
Summary: Last line of a particular page cut horizontally on reload
Alias: None
Product: Writer
Classification: Application
Component: viewing (show other issues)
Version: OOO310m9
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needmoreinfo, oooqa
Depends on:
Reported: 2009-04-16 04:39 UTC by mhrichter
Modified: 2017-05-20 11:15 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Test data file that (should) contain the issue (121.20 KB, application/vnd.oasis.opendocument.text)
2009-04-29 10:16 UTC, mhrichter
no flags Details
Screen shot of the problem (74.58 KB, image/png)
2009-04-29 19:18 UTC, mhrichter
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description mhrichter 2009-04-16 04:39:23 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

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).
Comment 1 Rainer Bielefeld 2009-04-16 07:44:37 UTC
Pls. attach a sample document (Using "Create a new attachment (proposed patch,
testcase, etc.)" on this page)!
Comment 2 mhrichter 2009-04-16 22:12:51 UTC
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.
Comment 3 eric.savary 2009-04-19 13:44:02 UTC
Feel free to reopen when you have a reproducible scenario and can attach a
sample document.
Comment 4 eric.savary 2009-04-19 13:44:17 UTC
Comment 5 mhrichter 2009-04-29 10:16:30 UTC
Created attachment 61880 [details]
Test data file that (should) contain the issue
Comment 6 mhrichter 2009-04-29 10:18:58 UTC
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.
Comment 7 mhrichter 2009-04-29 19:06:16 UTC
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.
Comment 8 mhrichter 2009-04-29 19:18:43 UTC
Created attachment 61896 [details]
Screen shot of the problem
Comment 9 mhrichter 2009-04-29 19:20:30 UTC
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).
Comment 10 eric.savary 2009-04-29 19:59:45 UTC
@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 
- do "Tools - Update - Update all" to see if it's not a temporary reformatting
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)
Comment 11 eric.savary 2009-04-29 20:00:05 UTC
Comment 12 mhrichter 2009-05-18 19:04:07 UTC
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.
Comment 13 mhrichter 2009-07-27 20:32:36 UTC
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.
Comment 14 mhrichter 2009-07-27 21:43:03 UTC
(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....
Comment 15 eric.savary 2009-07-27 22:59:06 UTC
Good news! Now I can reproduce it in a current DEV300m52 version on Vista! :)
So system independent.

The screenshot again:

The bugdoc attached in the wrong issue:

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.


- 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...
Comment 16 mhrichter 2009-07-29 08:28:15 UTC
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.
Comment 17 mhrichter 2009-08-19 17:49:42 UTC
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...).
Comment 18 mhrichter 2009-08-19 17:53:31 UTC
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.
Comment 19 mhrichter 2009-08-19 18:01:39 UTC
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.
Comment 20 mhrichter 2009-08-19 18:02:06 UTC
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.
Comment 21 dE 2011-12-19 08:03:10 UTC
On libreoffice atleast.
Comment 22 Marcus 2017-05-20 11:15:40 UTC
Reset assigne to the default "".