Bug 54703 - Hidden Sections are no longer hidden when printing or exporting pdf (see comment 16)
Summary: Hidden Sections are no longer hidden when printing or exporting pdf (see comm...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.4 release
Hardware: All All
: medium major
Assignee: Not Assigned
Keywords: bibisectNotNeeded, filter:pdf, regression
: 119874 128237 138273 (view as bug list)
Depends on:
Blocks: Mail-Merge PDF-Export
  Show dependency treegraph
Reported: 2012-09-09 21:18 UTC by wbaker
Modified: 2021-03-17 22:50 UTC (History)
20 users (show)

See Also:
Crash report or crash signature:

Testcase and results (368.33 KB, application/x-zip-compressed)
2015-09-05 18:11 UTC, ClDc
Crude Macro to Remove Hidden Fields and Convert Fields to Text (17.09 KB, application/vnd.oasis.opendocument.text)
2016-08-26 17:38 UTC, wbaker
mailmerge hidden paragraph (11.00 KB, application/vnd.oasis.opendocument.text)
2018-09-14 17:09 UTC, Oliver Brinzing
data source for mailmerge demo (9.65 KB, application/vnd.oasis.opendocument.text)
2018-09-14 17:09 UTC, Oliver Brinzing
simple example of sections - hidden conditionally and unconditionally for export test (11.51 KB, application/vnd.oasis.opendocument.text)
2020-01-18 13:32 UTC, sdc.blanco
Test.ods, Test.odt, div. .pdf (361.04 KB, application/x-zip-compressed)
2020-03-12 16:02 UTC, johi

Note You need to log in before you can comment on or make changes to this bug.
Description wbaker 2012-09-09 21:18:32 UTC
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.
Comment 1 ydutrieux 2012-12-17 16:05:17 UTC
Reproduced on libo Version (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
on platforms :
- Win7 - 32bits
- Ubuntu 12.04 64bits.
Comment 2 fmgtack+libreoffice 2013-01-18 08:39:36 UTC
Horrible regression, filed for 3.5.4 yet not fixed in (Ubuntu 12.10).
Comment 3 QA Administrators 2015-02-19 15:38:16 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-03-07 13:57:25 UTC
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:
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 5 wbaker 2015-08-07 00:39:19 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2015-08-07 17:59:39 UTC Comment hidden (obsolete)
Comment 7 wbaker 2015-08-10 19:20:29 UTC
Upgraded to Version 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?
Comment 8 wbaker 2015-08-10 21:59:04 UTC
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.
Comment 9 wbaker 2015-08-24 16:24:20 UTC
Update:  Using now LO 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.
Comment 10 Heinz Repp 2015-08-30 18:39:31 UTC
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 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).
Comment 11 ClDc 2015-09-05 18:11:03 UTC
Created attachment 118441 [details]
Testcase and results
Comment 12 ClDc 2015-09-05 18:17:29 UTC
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  on Windows 7 but all is broken with Version: (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  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

This text is about a person
------------------------------------------- 2 ------------------------------

“ Ms. Martine Dupont
20 rue du lac

This text is about a person”

----------------------------------------- 3---------------------------------


Document Foundation
5 rue du code

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  on Windows 10 + JRE 1.8.0_60 (X64)

Version: (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
20 rue du lac


This text is about a person


all the hidden paragraphs are displayed.

In unique document we see for “Dupont” :

“ 20 rue du lac

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”
Comment 13 ClDc 2015-10-28 17:33:37 UTC Comment hidden (obsolete)
Comment 14 ClDc 2015-12-02 18:00:22 UTC Comment hidden (obsolete)
Comment 15 ClDc 2015-12-08 17:01:11 UTC
I did other tests with :

Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale : fr-FR (fr_FR


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
Comment 16 Oliver Specht (CIB) 2015-12-09 14:29:11 UTC
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.
Comment 17 wbaker 2015-12-09 15:53:27 UTC Comment hidden (obsolete)
Comment 18 Heinz Repp 2016-05-26 10:32:57 UTC Comment hidden (obsolete)
Comment 19 wbaker 2016-08-26 17:38:31 UTC
Created attachment 127039 [details]
Crude Macro to Remove Hidden Fields and Convert Fields to Text

No better in

@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.

Comment 20 Oliver Specht (CIB) 2016-08-29 18:04:22 UTC
(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.
Comment 21 Xisco Faulí 2016-09-20 16:10:39 UTC Comment hidden (obsolete)
Comment 22 QA Administrators 2018-05-02 02:32:45 UTC Comment hidden (obsolete)
Comment 23 ClDc 2018-05-02 07:50:54 UTC

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: (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
19 rue du bois
post box 5
This text is about a person


instead of :

Mr. Pierre Durand
19 rue du bois
post box 5
This text is about a person

So for individual pdf file, the issue is not yet fixed

Thanks for your help
Comment 24 Alex Thurgood 2018-09-14 15:31:32 UTC
*** Bug 119874 has been marked as a duplicate of this bug. ***
Comment 25 Oliver Brinzing 2018-09-14 17:09:14 UTC
Created attachment 144871 [details]
mailmerge hidden paragraph

confirming with lo - single pdf export will show hidden paragraph
adding a simple test case with an embedded database
Comment 26 Oliver Brinzing 2018-09-14 17:09:52 UTC
Created attachment 144872 [details]
data source for mailmerge demo
Comment 27 wbaker 2019-02-27 01:18:00 UTC Comment hidden (no-value)
Comment 28 Mike Kaganski 2019-02-27 06:17:19 UTC
(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).
Comment 29 sdc.blanco 2020-01-18 13:32:12 UTC
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 and

If the problem is with using conditions from a database then maybe the bug summary should be changed to reflect this aspect.
Comment 30 User 2020-02-03 15:45:31 UTC
Problem persits in

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...;-()
Comment 31 johi 2020-03-12 16:02:57 UTC
Created attachment 158656 [details]
Test.ods, Test.odt, div. .pdf
Comment 32 johi 2020-03-12 16:08:39 UTC
perhaps it will be helpful - Problem persists (LO

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
Comment 33 johi 2020-03-13 11:06:00 UTC
... ok - I have to correct my text:

... all _conditions_ for hidden paragraphs are ignored ...
Comment 34 Timur 2020-11-17 10:45:12 UTC
*** Bug 128237 has been marked as a duplicate of this bug. ***
Comment 35 Timur 2020-11-17 10:46:27 UTC
*** Bug 138273 has been marked as a duplicate of this bug. ***