Download it now!
Bug 116394 - DocX Import - Word merge fields lose "=" character
Summary: DocX Import - Word merge fields lose "=" character
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium major
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Fields Regressions-expression-is-faulty
  Show dependency treegraph
Reported: 2018-03-14 04:12 UTC by Paul
Modified: 2019-09-16 01:19 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Minimal DOCX file showing 1 affected merge field. (11.27 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-03-14 04:18 UTC, Paul

Note You need to log in before you can comment on or make changes to this bug.
Description Paul 2018-03-14 04:12:23 UTC
DocX files lose the "=" symbol from merge fields when importing.
Works in version
Fails in version and later onwards 

Steps to Reproduce:
1.Load attached DocX
2.Examine the tool tip when hovering over the field (the = symbol is missing)
3.Save as ODT, examine content.xml - '=' symbol has been lost from "text:column-name" attribute

Actual Results:  
= symbol is lost

Expected Results:
= symbol is retained

Reproducible: Always

User Profile Reset: No

Additional Info:
This regression also means that when saving to DOCX the merge DocX file shows the incorrect text.

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Paul 2018-03-14 04:18:28 UTC
Created attachment 140626 [details]
Minimal DOCX file showing 1 affected merge field.

Good import (content.xml) looks like:
  <text:database-display ... text:column-name="ab=cd">

Bab import (content.xml) looks like:
  <text:database-display ... text:column-name="abcd">
Comment 2 Xisco Faulí 2018-03-14 10:08:19 UTC
Regression introduced by:

author	Jean-Sebastien Bevilacqua <>	2017-02-16 10:54:33 +0100
committer	Miklos Vajna <>	2017-03-30 17:39:00 +0000
commit	c568eb7d3bb4584867f0a1f0a7965f73097f009b (patch)
tree	ea7e6fb1e0d77369a90bc69dd8756f589bb352e4
parent	53c2507bf97867011fd2bfbbac6c86b7fc494338 (diff)
tdf#105975 Add Formula field parsing (docx) in SWriter

In MSWord, you can create a formula field (starting with =).
When you save your file as `docx`, this `FORMULA` field is registered
in you file (a field starting with `=`). In its current state,
LibreOffice can't parse the `FORMULA` field in `docx` file.

Context of this fix

This fix is entirely located in the `DomainMapper_Impl.cxx` file
because it's where the parsing is done.

How this fix works

First, we add `FORMULA` support by adding it to the `aFields[]` variable.
Next, to handle the `FORMULA` constant, we add a condition (swith case) in
`DomainMapper_Impl::CloseFieldCommand()` to call `handleFieldFormula`.


In function `lcl_ExtractToken`, if command starts with `=`, it's a
`FORMULA` field.

Bisected with: bibisect-linux-64-5.4

Adding Cc: to Jean-Sebastien Bevilacqua
Comment 3 Julien Nabet 2018-03-14 20:48:28 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
The pb is in these lines:
   2525             case '=':
   2526                 if (token.isEmpty())
   2527                 {
   2528                     rHaveToken = true;
   2529                     ++rIndex;
   2530                     return OUString("FORMULA");
   2531                 }
   2532             break;
in writerfilter/source/dmapper/DomainMapper_Impl.cxx

Miklos/Jean-Sebastien: thought you might be interested in this one following Xisco's comment