Create two sections with complimentary conditions to hide them so that their visibility toggles on the condition. Everything appears correctly on the screen. However, either printing or exporting the document resets the test somehow and all sections, including the hidden one, are printed, exported as pdf, and subsequently shown on the screen. Consequently, for any output, hidden sections seem useless.
Reproduced on libo Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7) on platforms : - Win7 - 32bits - Ubuntu 12.04 64bits.
Horrible regression, filed for 3.5.4 yet not fixed in 3.6.2.2 (Ubuntu 12.10).
** 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 (4.4.0.3 or later): 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
Added two sections (Insert - Section). Wrote stuff in them. Edited them (Format - Sections), added hide condition: TRUE so they will be immediately hidden. Printing & pdf export produce blank documents. Setting to WFM. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
Uh, not resolved. Am now up to version 4.2.8.2 Build ID: 420m0(Build:2). Same bug persists and absolute undermines a vast amount of work I've done hoping it would be resolved when I originally posted this bug in 2012! Maybe the test leading the the WFM was Windows specific, I don't know. However, I'm using Ubuntu 14.04lts with the above LibreOffice build and it acts just as when I first described the bug. I suspect there are many users of hidden sections (in Linux, anyway) because, if there were, and they were exporting to pdf or printing, they'd be reporting the same bug. I hasten to add that I have upgraded all hardware and software many times between the original bug report and now, three years later.
I tested it with 4.4, though not with 4.2, which has reached end of life Jan 6, 2015: https://wiki.documentfoundation.org/ReleasePlan/4.2#End_of_Life Please consider installing 4.4 with this PPA provided by Ubuntu team: https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-4-4 You might even try the freshest 5.0, but it might be a bit raw right now: https://launchpad.net/~libreoffice/+archive/ubuntu/ppa
Upgraded to Version 4.4.5.2 as suggested. Build ID: 40m0. Everything is worse. Hidden paragraphs fail entirely. Either remaining hidden or not hidden depending on something. The conditional variable changed. However, when sections are hidden, as originally reported, they reappear in pdf exports and printouts. None are hidden. So, it would appear that this problem is still present and that hidden paragraphs themselves have regressed. In either case, they don't remain hidden. Using Ubuntu 14.04lts. Thanks, but do you have any other suggestions?
I have a work around for the different behavior of hidden sections (as well as hidden paragraphs, and conditional text). The conditions used were simple and in accordance with the online libreoffice information. For example, it just used the query field name, eg. hide==1. However, it seems the new condition doesn't just rely on the query field name but requires more specificity such as database name, query name and field name. For example DB1.Letter_Query.hide==1. Then, at least, the hiding is displayed correctly on the computer screen. That said, my original bug remains. Whether hidden or not, all are shown in exported pdf documents or when printed to paper.
Update: Using now LO 5.0.0.5 and Ubuntu 14.04LTS. No change but I've found additional information by testing. In particular, hidden sections work properly with user input fields as conditions. They remain hidden when exporting as .pdf and as .docx. However, using a database query or table to provide the fields as conditions, the hidden sections are made visible again by exporting as .pdf or .docx. So, the behavior/bug remains but won't be confirmed by using fields that are not tied to a database as conditions to hide sections.
As a long time Open/LibreOffice user and long time user of hidden sections this bug bites me for the first time as a regression in LibreOffice 5. My use case is: A mail merge master document has multiple sections which are hidden on conditions from the database the document is filled from. When doing the mail merge, I create separate target documents as often I have to edit some after merging. Then I batch print all created documents. This worked for me ever since OpenOffice 2.x up to LibreOffice 4.x. Now, with LibreOffice 5.0.1.2 I was shocked to see all sections, hidden or not, be printed. Same holds true for export to PDF, a workaround I hoped it would work but didn't. This bug bites me on Ubuntu and Windows, it seems not to be platform specific. Surprisingly, the hidden sections are suppressed as they should when I print directly from the mail merge. So: Mail merge -> print to printer works, but Mail merge -> print to file, save merged document as individual documents exhibits the bug. Surprisingly, when I open the merged individual documents without editing them, I still can see the sections hidden where they should be. But while printing/exporting, the document is reformatted, and all hidden sections are shown (without marking the document as changed).
Created attachment 118441 [details] Testcase and results
In comment 11 I have attached a test case and its results May be I should have opened a new bug, but it looks like this issue, it is about hidden paragraphs and conditional text. All was working fine with LibreOffice 4.3.7.2 on Windows 7 but all is broken with Version: 5.0.1.2 (x64) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale : fr-FR (fr_FR) on Windows 10 + JRE 1.8.0_60 (X64) 1) oo_lo_hidden.Zip contains: 1.1) a data base test_hidden.odb which contains a table T_address 1.2) doc_to_print.odt which contains - for the first line, 3 hidden paragraphs if ident_code == 1 then ---> Mr. <firstName> <name> if ident_code == 2 then ---> Ms. <firstName> <name> if ident_code == 3 then ---> <name> Exactly one line, no less, no more should be printed - 1 hidden paragraph for the field adr2, if empty it should not be printed - a conditionned text if ident_code == 3 then ---> "an organization" else a person 2) Expected result can be found in folder result_lo_4.3.7.2 Generated with LibreOffice 4.3.7.2 on Windows 7 odt and pdf files are generated for individual and unique documents the content of the 3 documents should be ------------------------------------------ 1 ----------------------------- “Mr. Pierre Durand 19 rue du bois post box 5 Paris This text is about a person “ ------------------------------------------- 2 ------------------------------ “ Ms. Martine Dupont 20 rue du lac Toulouse This text is about a person” ----------------------------------------- 3--------------------------------- “ Document Foundation 5 rue du code Montreuil This text is about an organization “ This is correct with Loo_4.3.7.2 except “This text is about” which should not be bold in pages 2 and 3 of unic_doc.* files 3) unexpected results can be found in folder result_lo_5.0.1.2_x64 Generated with Loo 5.0.1.2_x64 on Windows 10 + JRE 1.8.0_60 (X64) Version: 5.0.1.2 (x64) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale : fr-FR (fr_FR) Each of of the file is wrong, pdf, odt, individual, unique in individual doc for “Dupont”we see : “ Mr. Martine Dupont Ms. Martine Dupont Dupont 20 rue du lac Toulouse This text is about a person “ all the hidden paragraphs are displayed. In unique document we see for “Dupont” : “ 20 rue du lac Toulouse This text is about a person “ The first line, a hidden paragraph is absent. Dupon0.pdf is wrong is contains the data of “Durand” Document Foundation0.pdf contains the data of “Durand”
Same behaviour with 5.0.2.2 Version: 5.0.2.2 Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale : fr-FR (fr_FR)
same with 5.1.0.0 Version: 5.1.0.0.alpha1+ (x64) Build ID: d667e3210b12c7ce3b3727e2a0e369a520fbaaa4 Threads 4; Ver: Windows 6.19; Render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2015-11-25_01:47:38 Locale: fr-FR (fr_FR)
I did other tests with : Version: 5.0.3.2 Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale : fr-FR (fr_FR and Version: 5.1.0.0.beta2+ Build ID: 52ac1a717b1869cb7d2ee710f50a15e216ced76c Threads 8; Ver: Windows 6.2; Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-1, Time: 2015-12-06_22:28:00 Locale: fr-FR (fr_FR) If I add the name of the table in the condition field it works for single pdf, single odt, individual odt but not for individual pdf
This is the result of a combination of changes: The first part is in SwDocUpdateField::_MakeFieldList() where all sections are switched to visible state to create a complete list of fields. The second part is a fix of https://bz.apache.org/ooo/show_bug.cgi?id=51035, 10 years ago, that skips evaluation of expressions that might be from databases that are not currently open. The last is a fix in SwXTextDocument::getRendererCount() that requests a field update before PDF export which is also called to create the print dialog preview. Im sure whether the problem in Coment 11 has the same / a similar cause. I think the right way to fix it is to get rid of the first part. After the condition result is overwritten one cannot decide what state the the right one.
(In reply to Oliver Specht from comment #16) > This is the result of a combination of changes: > The first part is in SwDocUpdateField::_MakeFieldList() where all sections > are switched to visible state to create a complete list of fields. > > The second part is a fix of https://bz.apache.org/ooo/show_bug.cgi?id=51035, > 10 years ago, that skips evaluation of expressions that might be from > databases that are not currently open. > > The last is a fix in SwXTextDocument::getRendererCount() that requests a > field update before PDF export which is also called to create the print > dialog preview. > > Im sure whether the problem in Coment 11 has the same / a similar cause. > > I think the right way to fix it is to get rid of the first part. After the > condition result is overwritten one cannot decide what state the the right > one. Oliver, You seem to be on to it. By making all fields visible, LO loses the WYSIWYG pdf export. In the mean time, I've developed a crude macro that enumerates the fields and actually removes those which are hidden. Unfortunately, this work-around affects the source document before exporting in pdf and means that the hidden fields are unfortunately lost forever. I look forward to any fixes you might create. Respectfully, Wil
@wbaker: Wil, would you mind sharing your macro? It could be helpful in the meantime as no one seems to be willing to pick up this bug - though Oliver in #16 already did a perfect analysis, but this LibO 5 regression did not yet find the attention it deserves.
Created attachment 127039 [details] Crude Macro to Remove Hidden Fields and Convert Fields to Text No better in 5.1.4.2 @Oliver: Is there a status on this? You seem to have perfectly identified the problem and it would appear to be a simple and final fix. In the meantime, I attach my crude macro (I gratefully acknowledge help from Andrew Pitonyak). It isn't perfect by any means but might help others waiting so long on this bug. For example, macro doesn't handle hidden fields inside tables. Wil
(In reply to wbaker from comment #17) > > Oliver, > You seem to be on to it. By making all fields visible, LO loses the WYSIWYG > pdf export. In the mean time, I've developed a crude macro that enumerates > the fields and actually removes those which are hidden. Unfortunately, this > work-around affects the source document before exporting in pdf and means > that the hidden fields are unfortunately lost forever. I look forward to > any fixes you might create. > Respectfully, > Wil Sorry, but at the moment I don't have enough time to take care of it.
Adding keyword 'bibisectRequest' to see whether this regression is already present in the oldest build of bibisect-43all repository or not. In case it's already present, change 'bibisectRequest' to 'preBibisect'. Otherwise, change 'bibisectRequest' to 'bibisected' and add a comment with the output from 'git bisect log'
** 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 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
Hi, About comments 11 and 12, I did on 2015-09-05 18:17:29 UTC With attached testcase. I have just tested today with : Version: 6.0.3.2 (x64) Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 Threads CPU : 8; OS : Windows 10.0; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: group I tested: - Creating one odt file ----> OK - Creating one PDF file -----> OK - Creating one odt file per line in table ---> OK - Creating one PDF file per line in the table --> wrong results for instance I get: " Mr. Pierre Durand Ms. Pierre Durand Durand 19 rue du bois post box 5 Paris This text is about a person " instead of : " Mr. Pierre Durand 19 rue du bois post box 5 Paris This text is about a person " So for individual pdf file, the issue is not yet fixed Thanks for your help
*** Bug 119874 has been marked as a duplicate of this bug. ***
Created attachment 144871 [details] mailmerge hidden paragraph confirming with lo 6.1.1.2 - single pdf export will show hidden paragraph adding a simple test case with an embedded database
Created attachment 144872 [details] data source for mailmerge demo
Seven years and no hope yet in sight... This bug persists in the very latest LO version. I checked today. Do I have to report it again or what is one to do?
(In reply to wbaker from comment #27) Any help is appreciated. You may find some friends who knows C++, and ask them to help fixing this. Or you may start a crowdfunding to attract developers. Or you may try doing that yourself - we are glad to help anyone who wants to get familiar with the codebase (just look at https://wiki.documentfoundation.org/Development, make your first build, join #libreoffice-dev, and ask questions). But it doesn't help to create duplicates. No amount of duplicates or bumps would make a developer to start working on this: only if a developer finds this interesting (i.e., a developer is affected by this; or knows the area and likes this sort of things and has free time; or has a paying customer asking to fix this; or something like that).
Created attachment 157240 [details] simple example of sections - hidden conditionally and unconditionally for export test Is this bug a problem with exporting sections (with Hide conditions) (in general)? Or a problem with using databases to control the Hide conditions? In relation to non-database cases: Could export hidden sections to PDF without them printing or being shown afterwards in the document. Here are the steps used in the test. (The attached testcase gives these steps, with the sections already created -- just need to "activate" the hide checkbox for Para 2 and Para 4). 1. Copy these five paragraphs into a New document. 2. Select this paragraph, use Insert>Section and set Hide (without condition) Should ‟disappear” from screen after “Insert” of section. And SHOULD NOT PRINT in export PDF 3. Select this paragraph, use Insert>Section (without hiding). Should remain on the screen after ‟Insert” command and should print in export. 4. Select this paragraph, use Insert>Section and set Hide (with condition: Hide==0) Should ‟disappear” from screen after “Insert” of section. And SHOULD NOT PRINT in export PDF 5. Export this document to PDF. Works with 6.3.4.2 and 6.5.0.0.alpha. If the problem is with using conditions from a database then maybe the bug summary should be changed to reflect this aspect.
Problem persits in 6.2.8.2 Hidden paragraphs are shown in a form letter based on a database printed to separate files in pdf. I resolved it in my case with the following work around: use "hidden text" instead of "hidden paragraph" - this works. (I just switched form Open office to libre office, in the former it worked...;-()
Created attachment 158656 [details] Test.ods, Test.odt, div. .pdf
perhaps it will be helpful - Problem persists (LO 6.4.1.2): when printing to a pdf it works different: when printing to several files all hidden paragraphs are ignored (see my testfiles in the previous post) - when printing all in one pdf it works fine. unfortunately the "work around" is not possible at this Point => data-fields are not allowed in hidden text tschau, johi
... ok - I have to correct my text: ... all _conditions_ for hidden paragraphs are ignored ...
*** Bug 128237 has been marked as a duplicate of this bug. ***
*** Bug 138273 has been marked as a duplicate of this bug. ***
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/868b45039d2d168e1c51d971b0d1e0589d4d11eb tdf#54703 fix unhiding at PDF export of cond. hidden sections It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/7e10b37030eb2a5afe783f078d36556d86da762e tdf#54703 fix unhiding at PDF export of cond. hidden sections It will be available in 7.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.