Created attachment 71956 [details] Compare the PDF files of the same ODT file using DiffPDF on Debian Linux Problem description: A word or words are moved to the next line in LibreOffice 4.0.0.0 Beta1. They are in the same line in LibreOffice 3.6.3. Steps to reproduce: 1. The operating system used is Linux debian 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux. 2. The OpenDocument Text (ODT) file can be found here: https://update.cabinetoffice.gov.uk/sites/default/files/resources/govt-ict-sip.odt 3. LibreOffice 3.6.3-> File-> Open-> (the file mentioned above)-> File-> Export as PDF (PDF/A-1a) 4. LibreOffice 4.0.0.0 Beta1-> File-> Open-> (the file mentioned above)-> File-> Export as PDF (PDF/A-1a) 5. Compare and contrast the two PDF files of the same ODT file. See the lines: ... [in LibreOffice 3.6.3] challenging the way we operate and provide services. The Government ICT Strategy, published in March 2011, described our longer term programmes of reform to improve Government ICT and deliver greater savings. This Strategic Implementation Plan provides a reference for central government and is designed to be read alongside the Government ICT Strategy ... [in LibreOffice 4.0.0.0 Beta1] challenging the way we operate and provide services. The Government ICT Strategy, published in March 2011, described our longer term programmes of reform to improve Government ICT and deliver greater savings. This Strategic Implementation Plan provides a reference for central government and is designed to be read alongside the Government ICT Strategy 6. The word Strategy and the comma are moved to the next line in LibreOffice 4.0.0.0 Beta1. The other words are also moved accordingly. 7. This issue is visible in the ODT file and the corresponding PDF file produced. Current behavior: Some words are moved to the next line. Expected behavior: Some words should stay in the same line. Operating System: Debian Version: 4.0.0.0.beta1 Last worked in: 3.6.3.2 release
Thanks for reporting! I can reproduce using 3.6.4.3 vs 4.0.0.1 (=RC1) using Mac OSX 10.8.2; Setting platforms to 'all'.
Since Joren can reproduce I'm marking as NEW and prioritizing. Normal (normal bug, can prevent high quality work) High (up from medium as it is a regression) bibisectrequest, I may get to this later today if not, can someone else bibisect it in the mean time? Thanks!
Another file seems to show the same problem: http://nysjcisenate.files.wordpress.com/2012/10/new-york-senate-minutes-of-oct-12-2012.odt Follow the comment (2012-12-22 03:12:18 UTC) and see the differences. A word or words are moved to the next line in LibreOffice 4.0.0.1.
Bibisection results: source-hash-cf16ef6c250a2755155a02f24bad861b35a1f92b commit cf16ef6c250a2755155a02f24bad861b35a1f92b Author: Michael Meeks <michael.meeks@novell.com> AuthorDate: Sat Sep 24 11:40:10 2011 +0100 Commit: Michael Meeks <michael.meeks@novell.com> CommitDate: Sat Sep 24 11:40:10 2011 +0100 add a 30 second timeout to failure if we get no response in this time # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect bad 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # bad: [598083cdb5699e7f45183da8b750815f62ff5485] source-hash-ecb1599ad00e71dfe05f3ae9a71bdce5f7540a40 git bisect bad 598083cdb5699e7f45183da8b750815f62ff5485 # bad: [7a67618d4eb83613b68e348711ae303d7a37f217] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e git bisect bad 7a67618d4eb83613b68e348711ae303d7a37f217 # bad: [0085537d37957cebdd863f1fec822463d6baa593] source-hash-e5f71ca7c27259360a401d94ed6a53038608b941 git bisect bad 0085537d37957cebdd863f1fec822463d6baa593 # good: [cb3831223efd865d92c0791154d21067cf5a8616] source-hash-a0a1c3f4fb730ed3614593c3d8ddb50c23204c29 git bisect good cb3831223efd865d92c0791154d21067cf5a8616 # bad: [e75a1aa7f65623e6a589a97a34754b1143411217] source-hash-a45732406540e0a3196506e184c00f664084588f git bisect bad e75a1aa7f65623e6a589a97a34754b1143411217 # bad: [e75a1aa7f65623e6a589a97a34754b1143411217] source-hash-a45732406540e0a3196506e184c00f664084588f git bisect bad e75a1aa7f65623e6a589a97a34754b1143411217 # good: [207d60455345050a0efbce0559eb6f5cb2544da7] source-hash-37f23f7d0d38e298f30b4810b651786cfe0a89bb git bisect good 207d60455345050a0efbce0559eb6f5cb2544da7 # bad: [5e827d326bcdca724100f88d034c93c9f62fa0ce] source-hash-cf16ef6c250a2755155a02f24bad861b35a1f92b git bisect bad 5e827d326bcdca724100f88d034c93c9f62fa0ce
Interestingly, works for me well again in 4.0.1 RC2 (SUSE distro package) and in master (self-built MinGW build). webofht-libreofficebugs002: Can you please check with the most recent LibreOffice, and tell us if you still see the issue there? Thank you!
Created attachment 77261 [details] The same issue is still there Using LibreOffice Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) on Debian Linux
cannot reproduce with document from comment #3 with current 3.6 / 4.0 / 4.2 branches - "diffpdf" detects some difference between 3.6 and 4.x but it's not really visible. document from description is apparently no longer available but it appears it's this one: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/85973/govt-ict-sip.odt the line breaking in the 2 paragraphs (12 pt Helvetica) is subtly different here on various different versions, e.g. OOo 3.3 different from AOO 3.4.0 different from (LO 3.5.7 / LO 3.6) different from (LO 4.0 / current master). it appears to me i don't have a genuine "Helvetica" font on my system (or at least no such entry in the "font" menu), i wonder if the reporter does have that? so i sort of doubt that there really is an actual regression here that needs fixing. what i did notice though is that line spacing is currently rather broken for this document for which i've filed bug 66690.
(In reply to comment #7) > > document from description is apparently no longer available but it appears > it's this one: > > https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/ > 85973/govt-ict-sip.odt Here is a backup of the file: https://www.dropbox.com/s/itq8n3785irsdus/govt-ict-sip.odt $ sha1sum govt-ict-sip.odt 1cfadbb0742699f1d4d0ddddb3572beff4a1ec28 My current LibreOffice is: Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 > > the line breaking in the 2 paragraphs (12 pt Helvetica) is subtly different > here on various different versions, e.g. OOo 3.3 different from AOO 3.4.0 > different from (LO 3.5.7 / LO 3.6) different from (LO 4.0 / current master). > > it appears to me i don't have a genuine "Helvetica" font on my system > (or at least no such entry in the "font" menu), i wonder if the reporter does > have that? I do not have the Helvetica font. > so i sort of doubt that there really is an actual regression here that needs > fixing. > It is the issue with this file: govt-ict-sip.odt .
(In reply to comment #7) > cannot reproduce with document from comment #3 with current 3.6 / 4.0 / 4.2 > branches - "diffpdf" detects some difference between 3.6 and 4.x but it's > not really visible. Now, I agree with you. I do not reproduce the same issue for the document from comment #3. I reproduce the issue with govt-ict-sip.odt .
Per Joel Madero, changing Whiteboard: bibisected40 -> bibisected
Hi, I checked both the UK(govt-ict-sip.odt) and the US (new-york-senate-minutes-of-oct-12-2012.odt) documents using: Versie: 4.2.0.1 Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a (on a Debian Linux machine) The behaviour is correct, PDF file and .ODT show the words in expected order. I set status to RESOLVED
(In reply to comment #11) > I set status to RESOLVED Hi Luc, Glad to hear it's fixed. Tested with document mentioned in Comment 8, I can confirm the behavior is again correct. Tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha0+ Build ID: 8102d45911bf3c47ce7ee15d3db89b0024c3bff8 TinderBox: Win-x86@39, Branch:master, Time: 2013-12-29_09:34:00 Just nitpicking: but lets mark it as WORKSFORME instead of FIXED; because we don't know which commit(/patch) fixed this behavior :-). Thanks for testing!
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]