[Libreoffice-bugs] [Bug 82097] REPORTBUILDER: Group Header keeps the values of the first group

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=82097

--- Comment #20 from Lionel Elie Mamane <lionel at mamane.lu> ---
> on current master i don't even see any fields in
> Writer because in /tmp/lu*.tmp/origine.odt styles.xml the
> report-builder generates a plain text "2014-01" string instead of
> a field like 4.1.6 did:

> i'm pretty sure this is responsible:

> commit fc92c1abebcfe9b18649d35b76bf22e001e332da
> Author:     Lionel Elie Mamane <lionel at mamane.lu>
> AuthorDate: Mon Aug 12 18:41:44 2013 +0200

>     fdo#67930 don't use variables for formattedtext in header/footer

>     I don't know why it was going through variables.
>     Instead, put the value where it is supposed to,
>     like for formattedtext in detail section.
>     Try it, and if something breaks, we can revert.

>     This also works around fdo#67930

> this commit was reverted in commit d6ce95ae2288859fe74d601f1bdaf616ab1ee7f0
> but then again un-revert in commit 08715e24c13d21767544725292d8dbf1c2381479

> and if i revert the latter on master i get the "variable-get" fields,
> but writer doesn't evaluate them like 4.1.6 did and the result is
> always 2014-01, (...)

> now, looking at this bug: a hard-coded string value in a header obviously
> cannot change between different pages; either report-builder actually needs
> to put those variables back in, or report-builder needs to generate
> multiple page styles with different hard-coded headers.

When I yanked the variables out, I didn't understand / see that these could
show up in a page header afterwards. All I was seeing is a variable that was
set, and then immediately used once, in the body of the document.

Now, we have an understanding of at least one "real role" these variables had:
 each new group opening (re)sets the variables
 if the group header is supposed to be repeated, it is placed in the page
header
 the page header uses the variables set

You now propose another way to achieve the same, namely Report Builder emits
constant values, but puts them in uniquely numbered page styles. I rather like
this idea, because the variables handling has proven to be a mess in the past:

 * Writer bugs
 * The OpenDocument spec specifies something different
   than what Report Builder expects, so Writer special cases (!!!)
   the constructs used by Report Builder!
 * Just plain fragility

But, I expect that for this to make sense, we need, each time a new (repeated)
group starts, to:

 * generate a new unique page style (theoretically no problem)
 * emit a tag that says "the *next* page will have this style"
   (_not_ the *current* page!)
 * that tag should _NOT_ force a page break

The point about not being a page break is absolutely crucial; Report Builder
has no clue where a page break will be, the page breaking _must_ be done
entirely by Writer.

Does such a tag exist? I didn't find out to set that in the Writer UI. Setting
"next style" shows some promise, but I'm afraid that is not it. I expect "next
style" must be set as a setting of the whole page style, and means that only
one page will have the current style. While what we need is:


<now page style 1/>
detail
detail
detail
...
...
many pages of detail, e.g. 5 pages
....
detail
<the next page, should have page style 2/>
detail
detail
detail
detail
...



while another document could be:

<now page style 1/>
detail
detail
<the next page, should have page style 2/>
detail
detail
<the next page, should have page style 3/>
detail
detail
<the next page, should have page style 4/>
detail
detail
<the next page, should have page style 5/>
detail
detail
... etc but no page break happens, so they page styles are never used...
....
....
<the next page, should have page style 12/>
detail
.... here the Writer layout engine decides a pagebreak is in order
... a new page starts, and it has page style 12

If such a tag doesn't exist, could we possibly get one? E.g. as a LibreOffice
extension, or something to be added to some future version of the standard, or
...?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170809/710e1f5e/attachment.html>