Created attachment 71937 [details] Compare the PDF files of the same ODT file using DiffPDF on Debian Linux Problem description: A space is found missing after the number and point. This is a software regression. 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 line: 10.Delivery of the Strategy is broadly divided into short term and longer term goals. Current behavior: The space between 10. and the word Delivery is present in LibreOffice 3.6.3, but this space is absent in LibreOffice 4.0.0.0 Beta1. Expected behavior: The space between 10. and the word Delivery is present. Operating System: Debian Version: 4.0.0.0.beta1 Last worked in: 3.6.3.2 release
Created attachment 72152 [details] test document
I was not able to download your test document, so I created one with LiBo 4.0beta2 (not beta1 you used), exported as pdf/a, then loaded with debian 3.6.2, exported as pdf/a, did a diffpdf, but shows that are the same. So or has been fixed in beta2, or I need your file to check and confirm. In any case with a new document created with beta2 seems not to be differences.
Created attachment 72153 [details] diff_pdf output
This issue exists in LibreOffice 4.0.0.0 Beta2. Testing the document: Here is the link to the document. https://www.dropbox.com/s/01f3jawoijetcub/govt-ict-sip.odt Please refer to page 10 of this document and its PDF file and the line: 10.Delivery of the Strategy is broadly divided into short term and longer term goals. I think I should not upload the document itself because of copyright issues. I am not the author of the document. Soon, I will remove the document (after fixing this issue). Regards, C. H. D.
I'm puzzled with this bug! First, I don't have (and probably you don't too) Helvetica font in my GNU/Linux installation. Just loading your document in Libo 3.6.2.1 and 4.0beta2 make a difference since i.e. Foreward paragraph is rendered different (spacing is a bit wider in 4.0 so lines end with different words since word wrap happened before). So if I load the document in Windows where Helvetica font exists, 3.6.x and 4.0 behave the same and the exported pdf is the same (see image attached). If I load the document in GNU/Linux, they are completely different even inside LO, so of course exporting in pdf can be any better. I've loaded the text in 3.6, selected all the text, Formatting -> Remove direct formatting, then produced a pdf from 3.6 and 4.0 and diff-pdf. Then are almost identical, except the "-" wordwrapping, and the bottom paragraph on page 2 ("Default’ services, using an Agile approach...") that 4.0 puts on next page due to the fact that word wraps the above line at "business" producing one more line than 3.6. In short I can't confirm the "10." issue you are raising, but I'm surfacing a different behaviour when fonts are not present in the guest OS, and also in some circumstances. A friendly suggestion / warning: you'd better try to produce a "copyright free", very short sample of the bug you find, that makes much easier to troubleshoot (i.e. have a look at the odt source code to check differences) and saves you from embarrassing positions. Once you put a file on the web, even if for a limited period, you completely loose control over it! Back to the bug, I don't know what to do, I can confirm that there is an issue, but is not the one reported even if probably related.
Created attachment 72217 [details] diff-pdf show equal pdf under Windows with Helvetica font present in the OS
Thanks for reporting. I'm not familiar with diffpdf, but I made a zip file with 4 pdf's, created with 4 different LibreOffice versions (see screenshots for version numbers). LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b Version 3.6.4.3 (Build ID: 2ef5aff) Version 4.0.0.0.beta1+ (Build ID: f4a1520c58f8bbbaf5027222c071374afb55961) TinderBox: MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm, Branch:libreoffice-4-0, Time: 2012-12-16_21:58:26 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51 All created on Mac OSX 10.8.2 Can you run a diff_pdf on this pdf's please? Kind regards, Joren
(In reply to comment #7) > Thanks for reporting. > > I'm not familiar with diffpdf, but I made a zip file with 4 pdf's, created > with 4 different LibreOffice versions (see screenshots for version numbers). https://www.dropbox.com/s/zdsn88n45gzzru3/govt-ict-sip-Mac-os-x.zip Can't upload it to attachment (-> size to big).
(In reply to comment #8) > (In reply to comment #7) > > Thanks for reporting. > > > > I'm not familiar with diffpdf, but I made a zip file with 4 pdf's, created > > with 4 different LibreOffice versions (see screenshots for version numbers). > > https://www.dropbox.com/s/zdsn88n45gzzru3/govt-ict-sip-Mac-os-x.zip > > Can't upload it to attachment (-> size to big). 1. I download Joren De Cuyper's attachment at https://www.dropbox.com/s/zdsn88n45gzzru3/govt-ict-sip-Mac-os-x.zip and found that it is probably the wrong file. This file begins with <!DOCTYPE html><html lang="en" xml:lang="en" class="" xmlns="http://www.w3... 2. I searched the Internet and found DiffPDF for Mac. I do not know if it works for you. If it works, feel free to use it to compare PDF files: http://download.cnet.com/DiffPDF/3000-18497_4-75745980.html http://www.qtrac.eu/diffpdf.html Regards, C. H. D.
(In reply to comment #5) > I'm puzzled with this bug! > First, I don't have (and probably you don't too) Helvetica font in my > GNU/Linux installation... 1. I compare the PDF files generated in LibreOffice 3.6.3 and 4.0.0.0 Beta2 on Windows 7. No difference is detected. However, the line in each PDF file is 10.Delivery of the Strategy is broadly divided into short term and longer term goals. i.e. no space between 10. and Delivery, as shown in Adobe Reader 9.5.1. In short, the expected space is not there. (This is an issue.) 2. The Helvetica font is installed on Windows 7, but LibreOffice does not recognize it. I look at the list of fonts in LibreOffice and cannot see it. I do not know why this font is a part of the issue. So, I have no idea. However, when I use Microsoft Office and I see that font in the list of fonts. 3. I think I do not look at the source of the file. I think it may be best not to alter the original file at first. I respect the copyright of the others. I will delete the file when the issue is fixed. I am afraid that it is very hard to reproduce the issue without the original file. Regards, C. H. D.
cannot reproduce the "wide" numbers that cause the missing space here on any 4.0.x version i tried (on Fedora 18). the attached image looks like the numbering uses a different font, which happens to be wider; most likely some font substitution is happening (for me as well, don't have Helvetica).
(In reply to comment #11) > cannot reproduce the "wide" numbers that cause the missing space > here on any 4.0.x version i tried (on Fedora 18). > I reproduce the missing space in LibreOffice Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 on Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux . Please copy and paste the line to see the difference. Thanks.
Changing 'regression' -> 'PossibleRegression' until we have independent confirmation of a regression.
Confirmed: Ubuntu 14.04 x64 Regression confirmed through bibisect New (confirmed) Trivial - doesn't even prevent high quality work, just makes it look slightly different, I'd be surprised if anyone would ever think it was a bug at all ;) Low The reason why I DO call it a bug is because when you save to other formats (for instance txt) there is a space - and I guess it looks *a tiny bit* cleaner with a space there. Interestingly enough the space was larger in older releases and then decreased a little, and ultimately just disappeared. Regression Bibisect: 59a69f706fe3c6e178a8ecda6fe82d72b0eef465 is the first bad commit commit 59a69f706fe3c6e178a8ecda6fe82d72b0eef465 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 04:11:24 2013 +0000 source-hash-48ad2f61fe71edc1a8967b322d3e0f368f4be06f commit 48ad2f61fe71edc1a8967b322d3e0f368f4be06f Author: Noel Grandin <noel@peralex.com> AuthorDate: Mon May 6 12:48:23 2013 +0200 Commit: Noel Grandin <noel@peralex.com> CommitDate: Wed May 8 08:06:44 2013 +0200 fdo#46808, Convert some code to getProcessComponentContext Change-Id: Ic59060818bf02a402610613a6bc97c5969a5c461 :100644 100644 ed068d33925e692916f67c5a192aeec1268a9133 e787c32d84b1d98f34ba920f7ff5357be1042b42 M autogen.log :100644 100644 c4c9e308e1ca8ff8876b1a661f7b6ffe85ddfab9 310762f2d0c8e2325f427377fbe9430527d7a8a5 M ccache.log :100644 100644 1ec20e507567e88bda397c1d5d4c9fa43b51de9c b1f4cb944cfbcbcde3f586fd7ed6748621aea329 M commitmsg :100644 100644 190c177f4ea075d2a9fe69a5374bf40baef16b56 80a5c6931ac7fc89b91ae4c8edd56e89a1304389 M dev-install.log :100644 100644 047a9f0b9e11087e048c85f74c1ea3fa27113a45 bcc004df72e1e634a48437c4f12d40a8cd30b4f7 M make.log :040000 040000 88b75396e52d119d087e07f453183d53bd376429 bba32c44c2c660f792cb727d96a99c5304c93822 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4 git bisect good 8ad82bc1416a07501651e8d96fe268e47d3931d3 # good: [d084d250b04446535ca1d7c29cf2062e6bd042b3] source-hash-688f72e3a2c3ef923389bbd21f6aea3afe1114db git bisect good d084d250b04446535ca1d7c29cf2062e6bd042b3 # bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0 git bisect bad c2069a369d738078124812312d51f21ea1ce2421 # bad: [e2a9149a7723f4e00eb3cafe466e204e5da19e9c] source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304 git bisect bad e2a9149a7723f4e00eb3cafe466e204e5da19e9c # bad: [f1fda5341557321cf4953c0d5dc6ffe262f1b545] source-hash-ee8323e2280c72eb5cc9ec0257164154b2580a78 git bisect bad f1fda5341557321cf4953c0d5dc6ffe262f1b545 # bad: [59a69f706fe3c6e178a8ecda6fe82d72b0eef465] source-hash-48ad2f61fe71edc1a8967b322d3e0f368f4be06f git bisect bad 59a69f706fe3c6e178a8ecda6fe82d72b0eef465 # good: [96f14f1bf7505b59a2731dcba1615568f03fd68f] source-hash-f0393d7ff69011a16b100541ef18e5090544e4a1 git bisect good 96f14f1bf7505b59a2731dcba1615568f03fd68f # first bad commit: [59a69f706fe3c6e178a8ecda6fe82d72b0eef465] source-hash-48ad2f61fe71edc1a8967b322d3e0f368f4be06f
git log f0393d7ff69011a16b100541ef18e5090544e4a1..48ad2f61fe71edc1a8967b322d3e0f368f4be06f --pretty=oneline sw/ shows only 9 writer commits in this range. This: commit 254c5c694bf2da98d5cf2693639251c6d4205920 Author: Miklos Vajna <vmiklos@suse.cz> Date: Tue May 7 12:08:41 2013 +0200 fdo#64256 writerfilter: handle void GraphicURL in ListsManager::lcl_sprm Change-Id: I4d8b1b527d5099781a36cc1265318c167205340e looks could be related as it tweaks in NumberingManager.cxx. @Miklos care to have a look?
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Miklos Vajna
Björn, the mentioned commit doesn't seem to be relevant, it's the numbering manager of the DOCX import, while here the bug is about an ODT import and PDF export. To the reporter: can you still reproduce this problem? There is one ODT attached to this bugreport. With that, I tried to do PDF export with LO 3.6 and 4.0, but I don't see any difference on the "10. xxx" lines. The other 3 attachments are PNG files, so they are not relevant. Is there still something to fix here?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170502
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170531