| Summary: | Writer table functions are not calculated before printing | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Tim Hardeck <thardeck> |
| Component: | Writer | Assignee: | Michael Stahl <mst.fdo> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | jmadero.dev |
| Version: | 4.0.0.0.beta1 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | target:4.1.0 target:4.0.0.1 | ||
| i915 platform: | i915 features: | ||
| Attachments: |
example document
possible solution for the issue - works for me but might not be the final fix |
||
Created attachment 71262 [details] [review] possible solution for the issue - works for me but might not be the final fix 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) 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. 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. 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.
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.