Description: A document with a large table (5 columns and 64 rows) is truncated when I export it to PDF with the --convert-to command line. Steps to Reproduce: From the command line run soffice.exe --convert-to pdf "Schedule of rent arrears.odt" on the attached document. Actual Results: The table is truncated so that the last row is missing. Expected Results: The table should be exported in its entirety. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Created attachment 131540 [details] Schedule of rent arrears.odt
I can't reproduce it in Version: 5.4.0.0.alpha0+ Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Created attachment 131550 [details] my output (correct)
Yes, it still fails with 5.3.0.3.
Could you please attach you output pdf document ?
Created attachment 131556 [details] Exported with 5.3.0.3.pdf Attached.
I do confirm it's only happening when using command line. Version: 5.4.0.0.alpha0+ Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Michael Stahl <mstahl@redhat.com> 2016-06-09 13:52:16 (GMT) committer Michael Stahl <mstahl@redhat.com> 2016-06-09 13:59:19 (GMT) commit c488214817516c13603deb1c180fef02f4c700bf (patch) tree f139da3173a9bf65a67d7d575af5d1ddc6a9d07a parent 6a5cb3dae1760283c2c9156de666964ea4794f0f (diff) tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_() The problem is that bBreakAfter is passed by reference to SwLayHelper and stored as a reference member there, so it has to live at least as long as pPageMaker. (Unfortunately C++ can't statically check that.) This then somehow caused the number of pages created after initial load to be 812 instead of the correct 396 determined from the layout-cache in the bugdoc, and that then caused Drawing objects to move backward during the following re-pagination, and then SwDrawContact::Changed_() calls SetFlyFrmAttr() and that sets the document to modified, which triggers the AutoSave that was reported in the bug. Adding Cc: to Michael Stahl
this is not a regression but a pre-existing condition that already affects the LO 3.3.0 release. the PDF filter calls CalcLayout via #0 0x00007f83d14224be in SwViewShell::CalcLayout() (this=this@entry=0x2d30ec0) at sw/source/core/view/viewsh.cxx:945 #1 0x00007f83d0fd90e0 in SwEditShell::CalcLayout() (this=0x2d30ec0) at sw/source/core/edit/edws.cxx:96 #2 0x00007f83d172d9a9 in SwXTextDocument::getRendererCount(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x2a2da40, rSelection=..., rxOptions=...) at sw/source/uibase/uno/unotxdoc.cxx:2572 #3 0x00007f83ccf37c7d in PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=this@entry=0x7fffaf253a40, rFile=..., rFilterData=uno::Sequence of length 32 = {...}) at filter/source/pdf/pdfexport.cxx:874 ... but somehow the layout isn't finished when CalcLayout returns.
the document contains a "layout-cache" that is completely bogus: debug:26706:1: nType P nIndex 29 2147483647 debug:26706:1: nType P nIndex 66 2147483647 debug:26706:1: nType P nIndex 105 2147483647 debug:26706:1: nType P nIndex 142 2147483647 debug:26706:1: nType P nIndex 178 2147483647 debug:26706:1: nType P nIndex 205 2147483647 debug:26706:1: nType P nIndex 229 2147483647 debug:26706:1: nType T nIndex 314 65535 a lot of these paragraphs are either inside tables (in which case the cache must contain T instead) or structural nodes of the table like end-nodes. mystery how that happened. meta.xml has meta:generator: OpenOffice/4.1.1$Win32 OpenOffice.org_project/411m6$Build-9775 but when i use AOO 4.1.1 on Linux to load&store the document, i get a sensible layout-cache like so: debug:26765:1: nType T nIndex 382 65535 debug:26765:1: nType T nIndex 790 65535 there are 64 tables in the document, each with 1 row iteration over the pages in SwLayAction::InternalAction() 1 2 1 3 4 * 1 ... the * is where the disaster happens: before that point page 4 has 46 tables on it; then we hit the loop-control in line 556 *twice* and so move only 41 tables backward instead of all of them. after that point we have pages with tables: 1) 21 2) 24 3) 13 4) 5 but page 4 is marked as Valid (due to the loop control), so it is not formatted again during this LayAction. when you use the UI then something will surely initiate another layout action to finish the formatting (the print dialog triggers about 3), but not so with --convert-to.
added a sanity check for the layout-cache, works great for this particular bugdoc but of course can't detect every problem fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a5374f2fdbd1e15c107133f55930cbc431edbd5 tdf#106237 sw: do some basic sanity checking on layout-cache It will be available in 5.4.0. 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 "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=137ad218db262fb3531215adbc88b7093b4999c7&h=libreoffice-5-3 tdf#106237 sw: do some basic sanity checking on layout-cache It will be available in 5.3.3. 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.