Bug 105153 - FILESAVE: DOCX: SwFieldIds::User not mapped to any field in DOCX - does WriteExpand (start at Comment7)
Summary: FILESAVE: DOCX: SwFieldIds::User not mapped to any field in DOCX - does Write...
Status: RESOLVED DUPLICATE of bug 68140
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Fields
  Show dependency treegraph
 
Reported: 2017-01-06 17:55 UTC by Xisco Faulí
Modified: 2020-07-16 13:23 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
MobileClientWorkReport - Customer 533455 Job 4528264.pdf: created by Word 2013 (58.90 KB, application/pdf)
2017-03-13 06:35 UTC, Justin L
Details
MobileClientWorkReport_beforeRegression.pdf: output from LO bibisect before the supposed regression (85.11 KB, application/pdf)
2017-03-13 06:42 UTC, Justin L
Details
MobileClientWorkReport_afterRegression.pdf: output from LO bibisect after the supposed regression (140.70 KB, application/pdf)
2017-03-13 06:44 UTC, Justin L
Details
UserField.odt: a minimal test document. Field lost when saving as .docx and .doc (11.29 KB, application/vnd.oasis.opendocument.text)
2017-04-27 15:09 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2017-01-06 17:55:11 UTC
Steps:
1. Open attachment 74944 [details] from bug 60957
2. Save it as .DOCX
3. Open the new .DOCX file

Observed behaviour: Layout has changed. Besides, if the saved document is open in MSO Word it contains 2 pages instead of one

Reproduced in:

Version: 5.4.0.0.alpha0+
Build ID: 7a1add76d542e9929c1feab9e06949990e236616
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 1 Xisco Faulí 2017-01-06 17:57:03 UTC
Regression introduced by:

author	Tamás Zolnai <tamas.zolnai@collabora.com>	2016-10-28 15:24:51 (GMT)
committer	Tamás Zolnai <tamas.zolnai@collabora.com>	2016-10-28 14:10:41 (GMT)
commit	b927c1f4b334f80d2c2965e5b7327d6b6a685105 (patch)
tree	81c858f4a49ac09608294088bb2ecab77b93be5a
parent	8a22bc93e0988188a87c0a787a9b32a7f74da84d (diff)
tdf#103544: DOCX exp.: Image loss when have a frame anchored to the same para.
Regression from:
83d51e5e52688c4c9bc0ad70a511458bb06a242d

Partly revert the commit causes this regression.
I checked the related bugs (tdf#78590,tdf#80748)
intended to be fixed by this commit and reverting
this part does not bring back the corruption.
I guess something changed in frames' and text boxes'
import in the meantime, because this MergeMarks::IGNORE
is useless now.

Adding Cc: to Tamás Zolnai
Comment 2 Justin L 2017-03-13 06:35:28 UTC
Created attachment 131842 [details]
MobileClientWorkReport - Customer 533455 Job 4528264.pdf: created by Word 2013
Comment 3 Justin L 2017-03-13 06:42:48 UTC
Created attachment 131843 [details]
MobileClientWorkReport_beforeRegression.pdf: output from LO bibisect before the supposed regression

I would not call this a regression.  The result of round-tripping this document before Tamás' commit was hardly correct/usable. Primarily, the substitution of the database internals instead of the database record data is the biggest problem in round-tripping.
After the so-called regression, more data is shown (because before it was simply discarded) and thus everything shifts down on the page.
Comment 4 Justin L 2017-03-13 06:44:32 UTC
Created attachment 131844 [details]
MobileClientWorkReport_afterRegression.pdf: output from LO bibisect after the supposed regression
Comment 5 Timur 2017-04-12 10:40:50 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2017-04-12 10:45:39 UTC
(In reply to Timur from comment #5)
> According to the previous comment, I remove "regression". 
> But I don't see the point of this bug. Fileopen is wrong in bug 60957,
> surely RT will also be wrong. Since Xisco confirmed his own bug, I set back
> to Unconfirmed for a second opinion.

Just for the record, I confirmed my own bug because I bisected and we have a rule of thumb that bisected bugs can be set to NEW automatically.
Comment 7 Justin L 2017-04-25 09:30:48 UTC
The round tripping problem - where database fields do not only print the result, but also "User Field XXXXX = " - is likely inherited from OOo.

using linux bibisect43all
-oldest (3.5):   opens poorly, saves only a small portion of the doc, and opens with "User Field xxx ="
-last36onmaster: opens poorly, saves OK, and opens with "User Field xxx ="
-last40onmaster: cannot open the test document
-last41onmaster: opens poorly, cannot save the test document
-last42onmaster: opens poorly, cannot save the test document
-last43onmaster: opens better, saves OK, and opens with "User Field xxx ="

When saving as .odt, the field variable is preserved as in the original.
When saving as .doc, only the text of the field value is saved, but the variable itself is lost.
When saving as .docx, both the text of the field name and the field value are saved, but the variable itself is lost.
Comment 8 Justin L 2017-04-27 15:09:33 UTC
Created attachment 132906 [details]
UserField.odt: a minimal test document. Field lost when saving as .docx and .doc
Comment 9 QA Administrators 2018-10-10 03:05:30 UTC Comment hidden (obsolete, spam)
Comment 10 Justin L 2020-07-16 09:19:22 UTC
fixed for DOCX in LO 7.0 by commit 676862bb8aa043f116615e5d0dac59254eaa8138
Author: Miklos Vajna on Thu Jan 30 10:21:08 2020 +0100
    DOCX export: implement support for user fields

    Updating the field doesn't work yet, that'll need additional markup in
    settings.xml.

    Change-Id: I562ae62cebcbd5ca474bd0f7a181773f8e515f5e
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87720
Comment 11 Timur 2020-07-16 13:23:55 UTC
If commit is known (thanks to Justin) than it's Fixed, but if it's already in a bug, looks like we may duplicate.

*** This bug has been marked as a duplicate of bug 68140 ***