Bug Hunting Session
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)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectNotNeeded, filter:pdf, regression
: 119874 (view as bug list)
Depends on:
Blocks: Mail-Merge PDF-Export
  Show dependency treegraph
 
Reported: 2012-09-09 21:18 UTC by wbaker
Modified: 2019-02-27 06:17 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Testcase and results (368.33 KB, application/x-zip-compressed)
2015-09-05 18:11 UTC, ClDc
Details
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
Details
mailmerge hidden paragraph (11.00 KB, application/vnd.oasis.opendocument.text)
2018-09-14 17:09 UTC, Oliver Brinzing
Details
data source for mailmerge demo (9.65 KB, application/vnd.oasis.opendocument.text)
2018-09-14 17:09 UTC, Oliver Brinzing
Details

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 4.0.0.0.beta1 (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 3.6.2.2 (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: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 5 wbaker 2015-08-07 00:39:19 UTC
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.
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 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?
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 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.
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 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).
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 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”
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 :

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
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
(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
Comment 18 Heinz Repp 2016-05-26 10:32:57 UTC
@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.
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 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
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
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'
Comment 22 QA Administrators 2018-05-02 02:32:45 UTC Comment hidden (obsolete)
Comment 23 ClDc 2018-05-02 07:50:54 UTC
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
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 6.1.1.2 - 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
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?
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).