Bug 58074 - Writer table functions are not calculated before printing
Summary: Writer table functions are not calculated before printing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 4.0.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Michael Stahl
QA Contact:
URL:
Whiteboard: target:4.1.0 target:4.0.0.1
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-10 10:33 UTC by Tim Hardeck
Modified: 2013-11-16 19:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
example document (10.77 KB, application/vnd.oasis.opendocument.text)
2012-12-10 10:33 UTC, Tim Hardeck
Details
possible solution for the issue - works for me but might not be the final fix (522 bytes, patch)
2012-12-10 10:35 UTC, Tim Hardeck
Details | Splinter Review

Description Tim Hardeck 2012-12-10 10:33:26 UTC
Created attachment 71261 [details]
example document

I have a document with tables which show the date of the week which gets calculated by the page number. This does work fine as long as the page is not printed.
As soon as the page is printed or exported as pdf every entry shows the same date.

I have attached an example document. Just click in one of the date fields and they get updated in the whole document. If you now export it as a pdf or print it all week entries show the same date.

I have created a patch which does fix the issue but I am not sure if it is the right one since it does basically prevent the default part from running in this case. So it might just hide an underlying issue but I also don't know why something should be marked as Modified with a non-existing element.

Like I have mentioned the date field has to be clicked at after loading the document otherwise all also show the same date. With my patch they get also updated by just printing/exporting the document.

Anyway I hadn't the time to look further into this.
Comment 1 Tim Hardeck 2012-12-10 10:35:23 UTC
Created attachment 71262 [details] [review]
possible solution for the issue - works for me but might not be the final fix
Comment 2 Joel Madero 2012-12-11 17:22:14 UTC
Confirmed that it's a problem, didn't test your patch but one of the devs can take a look at it (maybe send it out via mailing list if possible).

New (confirmed)

Version (changing to 3.6.3.2 as this is the oldest version it's been shown on, although I suspect it's been around a lot longer)

Normal (can prevent high quality work if you can't print correctly)

Medium (print should always be identical to what you see on screen, also enough people use fields like these to raise this issue to medium)
Comment 3 Not Assigned 2013-01-09 00:27:23 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=741e8b7b9d8e1a8f758edfe1c017801aa3d51247

fdo#58074: store page number in SwPageNumberField



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 Not Assigned 2013-01-09 00:33:23 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0cb7aa288537d8740f4781e0c38e4df7394888ab&h=libreoffice-4-0

fdo#58074: store page number in SwPageNumberField


It will be available in LibreOffice 4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 5 Michael Stahl 2013-01-09 10:54:54 UTC
so i was a bit afraid that this bug may be a regression from my changes
to field expansion in OOo 3.3, but it turns out that OOo 3.2.1 is even
more broken: there you don't need to print to mess up the table formulas,
it's sufficient to click on the table boxes to get the wrong results.

the problem is that all SwPageNumberFields share a single
SwPageNumberFieldType, and that contains the actual page number
used in the expansion; it turns out that making this expansion
(from SwTxtFld::Expand) always use the cache breaks the UNO
API SwXTextField, so that is not an option; the alternative is
to simply move the actual page number to the SwPageNumberField.

this only works if the field is in the body text; i have
no idea how to fix the case when the page number field is in
the header/footer, as in that case there is just a single
SwPageNumberField that has multiple "views" on it (one per page)
and each of these views needs to have a different value.

but i'm calling that a different bug :)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.