Created attachment 154851 [details]
"Smart" footer tries to insert variable-value controlled paragraphs

I enabled View>Formatting Marks and Field Names and also Tools>Options>LibreOffice Writer>Formatting Aids Display fields Hidden xxx to ease designing and debugging.

Consequently, use "Print preview" to see the results or disable the flags.

(In reply to ajlittoz from comment #0)
> 
> I am presently facing a typographic case where the LAST page of a sequence
> must be formatted differently. This is not the last page of the document
> (which could be detected with the "Next page" field returning a null value).
> Consequently, I added "set variable" fields in the main text flow to toggle
> the state of a flag variable. I use this flag value in a footer to control
> conditional insertion, but it does not work.
> 
> This special formatting can't be replaced by a page break to an ad-hoc page
> style, because there should be no page break in main text flow. It is really
> only a spot location, not a range, which needs to be flagged, something like
> a note, but in the footer area, not in the note area. And also, it must not
> cause conflicts with notes.
> 

So use case seems reasonable--if a bit of a corner case. 

Dynamic Conditional text in header/footer per page responding to fielded data of that page.

Alternatively multiple header/footer objects per document.

I see that severity has been changed from "bug" to enhancement". Could you please argument on that?

I admit that documentation is silent on this case (definitely a corner case) but in continuity with dynamic information like page number or chapter title, it should be updated based on page data.

Since there is no caveat nor limitation, I considered it a bug because behaviour of "simple" field and hidden object should be consistent.

We all know that developers are overbooked; therefore, categorising this report as "enhancement" leaves little hope for proper fix.

 Anyway, this is a request from my publisher (suppress footer page number on last page of every chapter) and I can't abide by it  but by a "dangerous" manual edit: anchor to page (with all the risks of this mode) a small white rectangle positioned over the page number field to hide it.

(In reply to ajlittoz from comment #3)
> I see that severity has been changed from "bug" to enhancement". Could you
> please argument on that?

Don't get it either. Neither what UX can do here.

How is this anything but an enhancment, OP is asking for implementation of a feature that does not exist for a workflow that is not in the mainstream.

Also, not clear that ODF archive will even hold the structure.

Variables are valid throughout the whole document. In your example, the first line with set=1 is overridden by the second "Set flag" operation. And the second flag=0 is taken into the footer of all pages.

Unfortunately. variables cannot take variable content such as the page number. From the documentation https://wiki.documentfoundation.org/images/b/bc/WG6017-Fields.pdf:

<documentation>
Conditional text
With conditional text, you can have two alternative texts (a word, phrase, or sentence). One text will be displayed and printed if the condition you specify is met, and the other will be displayed and printed if the condition is not met. You cannot include graphics or edit the text except in the field dialog (not in the body of the document). You also cannot format part of the text (for example, bolding one word but not the others), but you can format the field to affect
all of the field contents (for example, bolding all of the words). You cannot include a cross-reference or other field in the text.
...
Conditions are what programmers call logical expressions. You must formulate a logical expression for each condition because a condition is always either true (met) or false (not met). You can use the same condition in many places in your document, for different types of conditional content.
...
You cannot use internal variables (for example, page number, or chapter name) to formulate conditions.
</documentation>
(adding Olivier in case something is not clear at the documentation)


An idea to solve your "last page" problem might be, if it's about the header, to understand this last page as the first page of the next section.

I reread the documentation.

The problem is not in what can be put into conditional text/paragraph/section but in the condition itself in header/footer context.

It isn't clear at all WHEN this condition is computed.

I "expect" (this is where I might be wrong) that conditions are computed whenever we need to insert the header or footer in a page. It is obvious this is what happens with field content: field is inserted into its formatted location and, since it not text, its value is called for and replaces the field object.

Apparently (this is how I understand the behaviour, conditions are evaluated the FIRST TIME the header or footer is met and some form of parsing is performed on it. This allows to keep only a simplified representation with only text and fields (conditions resolved and removed). This parsed form is cached and used when the header or footer is needed.

If my interpretation is correct, I disagree with this design because the header or footer only reflects the state of variables (in the condition) existing in the first use of the page style. This restriction is not mentioned in the documentation.

I'd like the conditions to be treated exactly like fields are treated: use the value prevalent at time of insertion into the output page.

It is not an issue with ODF format because the header or footer contents already describes the conditional test, at least to be able to reload and display the document. It is a matter of implementation: as I said, the choice is between computing the condition the first time it is met in the header or footer, or at every occurrence of header/footer insertion.

Only inspection of source program could tell which course was followed. Unfortunately, I'm unable to do that.

Status RESOLVED/WORKSFORME does not answer the issue. Please reconsider the above arguments.

(In reply to Heiko Tietze from comment #6)

This valid request is not about using page numbers in variables, but about allowing specific dynamic content (conditions) in headers, like another kind of dynamic content (fields) is already supported.

Back to new.

(In reply to Mike Kaganski from comment #8)
> (In reply to Heiko Tietze from comment #6)
> 
> This valid request is not about using page numbers in variables, but about
> allowing specific dynamic content (conditions) in headers, like another kind
> of dynamic content (fields) is already supported.
> 
> Back to new.

Thanks Mike

(In reply to Mike Kaganski from comment #8)
> This valid request is not about using page numbers in variables, but about
> allowing specific dynamic content (conditions) in headers, like another kind
> of dynamic content (fields) is already supported.

ajlittoz sets a variable flag=0 on page 1 and flag=1 on page 2 and expects flag to be different on the two pages. This variable is not recalculated like in Calc, it is set and obviously overridden at the second time. => WF

What I wrote about using page numbers in variables it was a follow-up to this approach. Like set flag=page_number, but that's not possible.

So still a clear WF. Olivier is in CC in case the documentation is not clear enough on the topic.

(In reply to Heiko Tietze from comment #10)
> ajlittoz sets a variable flag=0 on page 1 and flag=1 on page 2 and expects
> flag to be different on the two pages. This variable is not recalculated
> like in Calc, it is set and obviously overridden at the second time. => WF

Let me try to clarify the one and the only issue here, so that we stop talking about unrelated stuff.

Open attachment 154851 [details], and *check* "Hidden paragraphs" under Options->LibreOffice Writer->View.

Look at footers. You see three paragraphs there. The top of them shows two dynamic pieces of data: one of them if "Page number" field (actually irrelevant and distracting here); the other is "Show variable" field.

How does *that* paragraph change over pages? It is obvious that these two pieces of dynamic content - notably "Show variable" field - update their value depending on which page the corresponding footer is shown. This is OK, and this is *wanted* behaviour.

Now take a look at the two following paragraphs in the footers. They also have a field each (a grey shaded tiny area before the first character of each of those paragraphs); and that is a "Hidden paragraph" field. That field has a condition; that condition depends on the variable (the same which is displayed in the paragraph above): the upper paragraph should hide when "flag==0", and the lower should hide when "flag!=0". But unlike the "Show variable" field, changing the variable in the text body does *not* affect the "Hidden paragraph" field in the footer: if it did, then in each page's footer, *current* value of the variable would determine which of the two paragraphs is made visible, so each page's footer would have own paragraph shown.

So here is *inconsistency* that the same change of variable *dynamically affects* one kind of fields in footers, bug *does not dynamically affect* other kind of fields in footer.

This becomes evident when you disable "Hidden paragraphs" under Options->LibreOffice Writer->View again (or use print preview). You will see that in each footer, the same paragraph ("Variable flag is null") is visible on all pages.

Again: the issue here is *inconsistency* of dynamic evaluation of the field value between different field types.

(In reply to Mike Kaganski from comment #11)
> Now take a look at the two following paragraphs in the footers.

Page 1 sets flag=1 and on the same page flag=0 resulting in flag==0 at the footer of page 1 and 2. 
Page 3 sets flag = 0 and shows 0 at the footer, at page 4 we set flag=1 and get flag==1. Deleting the page break between p3 and 4 results in the same as on p1 with flag==0.

So obviously the variable is evaluated per page (I was wrong with throughout the whole document). Is this wrong? Or does it need documentation?

(In reply to Heiko Tietze from comment #12)
> Page 1 sets flag=1 and on the same page flag=0 resulting in flag==0 at the
> footer of page 1 and 2. 
> Page 3 sets flag = 0 and shows 0 at the footer, at page 4 we set flag=1 and
> get flag==1. Deleting the page break between p3 and 4 results in the same as
> on p1 with flag==0.
> 
> So obviously the variable is evaluated per page (I was wrong with throughout
> the whole document). Is this wrong?

No! This is perfectly OK and nice.

> Or does it need documentation?

Well - no idea here, and possibly for some, it would be nice to be documented; but that is *not* the issue here.

The issue is that its active value on the page, while correctly and expectedly affecting one of the fields ("Show variable" field), does *not* affect the other field that also depends on the variable (I mean "Hidden paragraph" field).

Once again, thanks Mike: you have perfectly understood my point with the attachment and you clarified my intent.

I should have added explanations/comments in the attachment to explicitly tell what I expected.

The first paragraph in the footer is there to echo the current value of the variables. Paragraphs 2 and 3 (with complementary conditions) are there as a usage of "hidden paragraph" field. They are both there to ensure that "hidden paragraph" is working in a footer: either one or the other should produce output. If none, then there is a bug in the feature (which is not the case).

You rightfully pointed out the *inconsistency* of field evaluation related to variables ("show variable" vs. condition in "hidden paragraph").

Without looking at the code, I have the feeling that conditions are evaluated when the footer is first met as *early evaluation* which has the advantage of caching a simplified version on footer content where you no longer need to compute expressions afterwards. Unfortunately, it results in the demonstrated inconsistency.

I don't know if this may be a clue or not to the cause of the problem.

Created attachment 155383 [details]
Test scenario

Now I got it ;-).

While "Show" always returns the last value on the current page it's the first variable in case of hidden text or paragraph. Would treat this as a bug.

Another user experienced the same bug. See https://ask.libreoffice.org/en/question/226180/show-field-variable-in-header-from-first-setter-on-page/

Bug still present in 7.3.4.2