In some pages some footnotes get skipped when printing, including PDF exporting. For example, in the following document at page 39 and 40 footnote 104 gets discarded and footnote 105 gets the separator over it. You can get the PDF here: http://rnbc.dyndns.org/pub/Negociantes,_Mercadores_e_Traficantes_-_160x230v2.pdf I can send the ODF by email if needed. If I change widow/orphan control in footnotes, or any other style that changes pagination the problem gets sorted out in some pages, but appears in others (more or less randomly). This occurs both in Linux and Windows with the latest version of LibreOffice (4.2, but also 4.1 and 4.0), albeit not in the same pages, because the pagination is slightly different between those 2 OSes.
I used these fonts: http://numbertext.org/linux/ The ODT file is online at the same address.
I mean the ODT is at the same address as the PDF...
Created attachment 93812 [details] page 39 footnotes
Hello Rodrigo Nuno Bragança da Cunha, At this step, there's another way, perhaps, than using widow and orphan to get the correct behavior. This is to slightly reduce the space between caracters, as I show it for page 39 in attachment: To see where to win some space, left align the paragraph. Select "agora da Casa de Negocio desta Cidade, que existia debaixo da firma de Trumpy e Companhia, ", including coma and space behind Companhia, right click and in context menu select Character, next > Position tab > Spacing > Choose Condensed and 0.2 pt. Justify again your paragraph. Footnote 102 is reduced the same way. Pagination is kept and this can save a big amount of work. Does this help? Kind regards, Jacques
Yes, thanks! Actually I had already solved the issue by playing a bit with margins, footnote separator, widow/orphan... Pagination changes a bit, et voilà! Problem goes away... sometimes, for some combinations! Change them a bit and it reappears, in another page, sometimes in 2 or 3 pages. Worst: if the problem is solved in Windows, for example, and I open the document in Linux, a new tweaking is needed because the pages change a bit (the font rendering changes a bit). I understood this happened in difficult situations, when the footnotes and the text clash with each other at the end of pages. In normal documents it's probably never an issue. But this one has many footnotes, and the page size is relatively small. It's difficult to format correctly, I know. But isn't this a bug? I mean: the document is correctly formatted on screen, so the algorithms are already there, operating well. Perhaps it's a good test case for improving LibreOffice :) PS: Disabling widow and orphan control alone in footnotes doesn't solve the issue.
Please check... http://rnbc.dyndns.org/pub/Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.pdf ...where the problem is apparent at page 39 and 40. I just changed the footnote separator margin a bit (0.05cm below and 0.10cm above). As usual the ODT is at the same place.
PS: Sorry, in my first example the problem was invisible by my mistake. Now in this latest example it's clearly visible. By formatting the document in slightly different ways I've seen problems in pages 40, 47, 75, 82. It depends on luck...
Just to change the file URL, which is now: http://rnbc.dynip.sapo.pt/pub/Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.pdf
Dear Rodrigo, Can you please upload the original odt file as i'm unable to access it.
Hi Jay, Just change pdf estension by odt. This is enough I think. Kind regards, Jacques
Hello Rodrigo, I can confirm its there on Linux Mint with 3.3.0, 3.6.7, 4.2.5 and master. It seems as if the repagination isnt doing a complete job, as when you go into print preview mode it repaginates all the pages, but still after going to a page that has the problem, it shows the error and then corrects its self a few seconds later.
Jay Philips, I agree with your assessment. That's what I thought too... and that's what I saw. There seems to be a two-pass algorithm doing the pagination job in preview mode and in print mode only the first pass runs, leaving footnotes badly formated, lost, etc... PS: I have no knowledge of the internals of LibreOffice, so my opinion has little weight.
I agree that this is an error and hope that it will be fixed some time. It cost me quite a lot of time and nerves to get a 450 pages document with around 2400 footnotes into a correct PDF. The problem seems to be related to Postscript output - it appears in exported PDFs as well as in Postscript files generated via "print to file". The workaround using letter spacing worked in some cases, but also often produced ugly text. My preferred workaroung was to add empty lines where LO added empty space between text and footnote separator line. This seems to give LO less freedom to shift footnotes around and thus avoids the "jumping" separator line. Actually, I have seen to different forms of what seems to be the same problem: a) footnote separator line remains where it should be, but the page below this line is empty b) footnote separator line "jumps" down a bit (or footnotes jump up?) so that the line runs through the footnote
I forgot to mention that I tested this yesterday and observed the same behaviour in 3.5.2 and 4.4.1.2.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Created attachment 124402 [details] Example created with 5.0.5.2 on Windows 10
The bug is still present in 5.0.5.2 on Windows 10. I _think_ the behaviour is identical to what I saw in March 2015. An example is attached: Footnote 285 is incomplete and 286-290 are not shown at all.
I confirm this bug is present in the latest incarnation of LibreOffice. Just tested 5.1.2.2 and still have missing and badly formatted footnotes, as before.
I can reproduce the render of separator over the footnotes text in libreoffice 5.2.5.1, exporting to PDF. In my case I think it is bound to the widow and orphan lines (I set it to 3 each) and mix of paragraph styles in every page; in a 200 page document with footnotes in each page, maybe 5% of the pages have the separator painted over the text.
Cannot download the test documents anymore. Please attach.
Above comment appears to apply to Rodrigos documents. Mine is already attached.
The URL is no longer rnbc.dyndns.org, as you can see in the following comments. Anyway, here goes again: http://rnbc.dynip.sapo.pt/pub/Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.pdf http://rnbc.dynip.sapo.pt/pub/Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.odt Eventually, in a few years, I'll have to change it again. Hopefully the bug will be solved by then :)
Created attachment 137495 [details] Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.odt
Created attachment 137496 [details] Negociantes,_Mercadores_e_Traficantes_-_160x230v2problem_in_footnotes.pdf
(In reply to Justin L from comment #20) > Cannot download the test documents anymore. Please attach. Attached the files to bugzilla. Note: this is an ODT issue and not a DOCX.
I said in June that I could reproduce the issue with 5.2.5.1. Today I tried with 5.3.1.2 and I cannot reproduce it anymore. Neither with my document or the attachment 137495 [details].
Created attachment 137530 [details] Bug in footnotes, pages 46 and 47 This exemplifies the bug in pages 46 and 47.
Created attachment 137531 [details] Bug in footnotes, pages 46 and 47 This exemplifies the bug in pages 46 and 47.
The bug still occurs. Version: 5.3.7.2 (x64) Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: pt-PT (pt_PT); Calc: group Check the documents I just attached, pages 46-47: "Negociantes, Mercadores e Traficantes - 160x230v5-1.odt" "Negociantes, Mercadores e Traficantes - 160x230v5-1.pdf"
Right, I confirm that the bug still occurs in the 5.3.1.2 I have at hand. To add some information, in my document of ~200 pages (private document), it happens twice. In one case, one footnote is missing (footnote number 62), and the separator is over the footnote 63. In another case, only the separator is moved over the footnote text (over footnote 202). If I generate a PDF of only the page of footnote 62, both the separator and the footnote appear correctly. They appear broken generating the full document PDF. I have a libreoffice built in debug to evalute it and I'm capable of C++; if anyone has some clue of where to look, where to breakpoint and watch, let me know. In the past I saw this happen with Type 1 fonts, but this happens to me with OTF fonts now as well.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a172f854b6e1d61bf0fe0fe4efc3058bb7a760bf tdf#74693: Footnotes text appearing above footnote separator line It will be available in 6.1.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.
My commit fixes the issue in the document attached here: https://bugs.documentfoundation.org/show_bug.cgi?id=74693#c28 but I still see the issue in the other version of the document: https://bugs.documentfoundation.org/show_bug.cgi?id=74693#c22
I'd just like to add that this problem still persists in the most recent daily I checked on OS X. I am on the verge of publishing a 390-page dissertation and now this has started to happen since I applied the final formatting guidelines that I need to follow… If that helps: I think the problem is the positioning of the footnote text. It gets positioned too high, therefore footnotes are cut off and footnote text appears in front of/above the separator line.
Dear Rodrigo Nuno Bragança da Cunha, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have tested with: Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: pt-PT (pt_PT); Calc: group threaded Seems to work fine now. I have tested with a few documents that previously had problems. Thanks!
Created attachment 151747 [details] pdf with a bug on page 89 (92)
Created attachment 151748 [details] odt (source of pdf with a bug on page 92)
Still appears on Version: 6.1.6.3 Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: ru-RU (en_GB.utf8); Calc: group threaded Attachments: pdf with a bug on page 89 (92) odt (source of pdf with a bug on page 92)
(In reply to Georgy from comment #38) > Still appears on > Version: 6.1.6.3 > Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 > CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; > Locale: ru-RU (en_GB.utf8); Calc: group threaded > Attachments: > pdf with a bug on page 89 (92) > odt (source of pdf with a bug on page 92) I can't reproduce it in Version: 6.3.0.0.alpha1+ Build ID: aa687b22991e6c674b1d8653d52fbe9a50080174 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded is it only exporting to PDF or also displayed it ?
(In reply to Xisco Faulí from comment #39) > (In reply to Georgy from comment #38) > > Still appears on > > Version: 6.1.6.3 > > Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 > > CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; > > Locale: ru-RU (en_GB.utf8); Calc: group threaded > > Attachments: > > pdf with a bug on page 89 (92) > > odt (source of pdf with a bug on page 92) > > I can't reproduce it in It's not repoducing in 6.3.0 for me too. > > Version: 6.3.0.0.alpha1+ > Build ID: aa687b22991e6c674b1d8653d52fbe9a50080174 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > is it only exporting to PDF or also displayed it ? That one was only visible in PDF. I had another example that was reproducible in 6.3.0 and visible in Writer too. I fixed it by turning on automatic hyphenation in default paragraph style. I will try to find it and attach here.
Created attachment 168752 [details] New file to reproduce the bug Bug appears on page 89. Footnote line strikethrough footnote 28 after export to PDF.
Created attachment 168753 [details] PDF with bug visible on 89 page
Created attachment 171359 [details] file for debugging This file has lorem ipsum text (88 pages) and 2 last pages represent the bug. It was made from previous attachment. Bug only reproduce if before 2 pages with bug there is a lot of text, does not matter what text it is.
Dear Rodrigo Nuno Bragança da Cunha, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
As I has said previously on 2019-05-19 17:00:51 UTC this problem no longer affects me. Seems to be solved, as far as I'm concerned.