Created attachment 161351 [details] example file made with V6.4.3.2 (In pursuit of https://ask.libreoffice.org/en/question/246102/) A TextField of type DateTime inserted into the Header or Footer of a PageStyle in a text document does not (at least not always) retain a user-defined NumberFormat when saved. In examples the format was changed to a default related to the document language. That the error occurred on save is the conclusion from a glance into the content.xml This is a regression the latest older version I tested with was V6.2.5. It did not show the issue. V7.0.0.0.alpha1 also has the bug.
I only reported the bug concernig TextField of type DateTime. Since, however, I found that also a numeric TextField.User was afflicted in the respective way. In addition: The created master had 3 dependent TextField_s, two of them in the TextBody. Only the NumberFormat of the dependent field in the Header was changed without permission.
Maybe another AskLO question https://ask.libreoffice.org/en/question/246102/why-doesnt-writer-remember-my-custom-formatted-date-field/ could be affected by the same bug.
(In reply to ajlittoz from comment #2) > Maybe another AskLO question > https://ask.libreoffice.org/en/question/246102/why-doesnt-writer-remember-my- > custom-formatted-date-field/ could be affected by the same bug. This was the ask.libreoffice question I had linked to anyway ("in pursuit of..."). Why did you remove the keyword "regression"?
I confirm it with Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL but not with Version: 6.1.6.3 (x64) Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: group threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=59ace23c367f83491a37e844d16f7d716eff6346 author Maxim Monastirsky <momonasmon@gmail.com> 2020-02-21 02:35:55 +0200 committer Michael Stahl <michael.stahl@cib.de> 2020-02-27 19:04:33 +0100 commit 59ace23c367f83491a37e844d16f7d716eff6346 (patch) tree af47d9b808037e3af045678b60b73e47b6f1121f parent 5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (diff) tdf#101710 Fix invalid style:data-style-name attribute Bisected with: bibisect-linux64-6.5 Adding Cc: to Maxim Monastirsky
Created attachment 161573 [details] number style in <office:styles> I don't think, that the mentioned commit is the whole problem. But it might have uncovered the underlying cause. If the <number:date-style> is in <office:styles> and not in <office:automatic-styles>, then the field in the header does not find the style. That problem is inherit from OOo. But because it is a user-defined date style, I think, that <office:styles> is the correct place for it.
This is very odd. It seems to me that this happens only with odt files, but not with fodt files (in both cases the date style is under <office:styles>). Can someone else confirm this observation?
*** Bug 133617 has been marked as a duplicate of this bug. ***
(In reply to Maxim Monastirsky from comment #7) > Can someone else confirm this observation? Yes, I can confirm it with Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
What I found so far: The field code indeed seems to use automatic styles, with one exception: During the import of <office:automatic-styles>, there is a special code in the SvXMLImport::SetAutoStyles method that inserts already existing number styles into automatic styles as well. But for this to happen, the mnImportFlags member must include the SvXMLImportFlags::CONTENT flag. For the fodt import, this method is called just once with mnImportFlags == SvXMLImportFlags::ALL. That's when the number style from <office:styles> is inserted into automatic styles, and later consumed from there by the header field. But for odt, this method is called twice, because there is <office:automatic-styles> in both styles.xml and content.xml: - For styles.xml, it's called with mnImportFlags == (SvXMLImportFlags::STYLES | SvXMLImportFlags::MASTERSTYLES | SvXMLImportFlags::AUTOSTYLES | SvXMLImportFlags::FONTDECLS), so the number style isn't inserted into automatic styles, and later can't be found by the header. - For content.xml, it's finally called with mnImportFlags == (SvXMLImportFlags::AUTOSTYLES | SvXMLImportFlags::CONTENT | SvXMLImportFlags::SCRIPTS | SvXMLImportFlags::FONTDECLS). But while the number style is inserted, it has no use here, as the header is defined in styles.xml, and was processed already.
(In reply to Regina Henschel from comment #6) > Created attachment 161573 [details] > number style in <office:styles> > > I don't think, that the mentioned commit is the whole problem. But it might > have uncovered the underlying cause. > > If the <number:date-style> is in <office:styles> and not in > <office:automatic-styles>, then the field in the header does not find the > style. That problem is inherit from OOo. > > But because it is a user-defined date style, I think, that <office:styles> > is the correct place for it. Based on just a faint hope to understand better: In what way should the bug's "underlying cause" have been covered by versions where it was present in but did not become manifest?
(In reply to Wolfgang Jäger from comment #11) > (In reply to Regina Henschel from comment #6) > Based on just a faint hope to understand better: > In what way should the bug's "underlying cause" have been covered by > versions where it was present in but did not become manifest? Older versions have written the user-defined number format to <office:automatic-styles> in styles.xml. So it was not detected, that the field in header/footer could not use a number format, that was in <office:styles>. But newer versions write the user-defined number format to <office:styles> and now the error becomes visible.
I think this will solve the file open problem: https://gerrit.libreoffice.org/c/core/+/95612/
Turns out not only headers and footers are affected. Document fields indeed keep the number format itself, but lose the language setting. If I won't find a solution in a few days, guess I'll just revert the export part of bug 101710 for now.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd0dc1bc592d7952c36659da33d99ab964fe2e93 tdf#133459 Fix import of fields with user defined number formats It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/30096602870e80d13158c32d82a34002e65374ef tdf#133459 Fix import of fields with user defined number formats It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/2c2820b98c62e8de0806fd79c34b5fcf37f00c7e tdf#133459 Fix import of fields with user defined number formats It will be available in 6.4.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.1.0.0.alpha0+ Build ID: 11d21b3c1f7754b5d13ae9ea88da562ec74366ff CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Maxim. thanks for fixing this issue!!
*** Bug 134230 has been marked as a duplicate of this bug. ***
*** Bug 133130 has been marked as a duplicate of this bug. ***