Created attachment 98286 [details] Test document Tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha1+ Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46 How to reproduce: * Open attached bug document * Scroll to page 10 Behavior: starting from the image with the 'building with the tux pingiun', image caption is lost. It is placed behind the picture itself. If you drag the green bordered frame a bit, it'll pop into the correct place (see screenshot LibreOffice 4.3). This makes some sentences moving, which will result in some alignment errors. Kind regards, Joren
Created attachment 98288 [details] libreoffice 4.3
Created attachment 98289 [details] libreoffice 4.2 screenshot
Created attachment 98290 [details] Comparison 4.2 vs 4.3
I can confirm that behavior on Win7 x64 with Version: 4.3.0.0.alpha1+ Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46 a
very odd... on 4.2 branch point can reproduce it _only_ if scrolling right after the file is loaded with the mouse wheel... when waiting a few seconds, scrolling immediately by PgDn or scrollbar, caption is there... on current 4.2 and 4.1.6 the caption is consistently there. on master the caption is consistently missing. problem reproduces very well with 4.0.6 while 3.6.7 and older don't have problem. get bunch of these assertions when it's failing: warn:legacy.osl:31722:1:sw/source/core/layout/flylay.cxx:946: ::CalcClipRect(..) - frame, vertical position is oriented at, is missing . warn:legacy.osl:31722:1:sw/source/core/layout/flylay.cxx:444: <SwFlyFreeFrm::CheckClip(..)> - fly frame has negative height now. so for master this commit made it occur more often, specifically the pDocSh->GetPreviewMetaFile() which does some additional layouting: commit e2eda70f2746f08376d8cdf5e5360df217335aef Author: Jan Holesovsky <kendy@collabora.com> AuthorDate: Tue Feb 4 00:33:14 2014 +0100 startcenter: fdo#72469: Thumbnails also for other file types than ODF. ... the reason why that commit changes things is that when the MetaFile is produced, the drawing layers are painted with no ViewPort (ClippingArea) set, which causes *all* fly-frames to be painted; most of them have not been layouted at that point and apparently they are not properly layouted during painting (hence the numerous assertions), and the particular one on page 10 is layouted in such a way that it remains broken later. setting the ViewPort should fix things quite a bit, as it has already fixed some other problems with printing in OOo history.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa68e1309450f79d1b40545ad6c340a49eff51c6 fdo#78149: set the ViewPort even when painting to a MetaFile The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6dc48ef517b60adb7cfe09a65773d4ff7d69489c fdo#78149: assert if SwVirtFlyDrawObj is being painted with no ViewPort set The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.