diff options
author | Justin Luth <justin_luth@sil.org> | 2022-03-09 11:38:26 +0200 |
---|---|---|
committer | Justin Luth <jluth@mail.com> | 2022-03-22 11:39:34 +0100 |
commit | 377e6f7e8556516b6d1698c58857a5662e6f5660 (patch) | |
tree | 64a260576fa2b030be2db5e24e4e7b6901d7d3a1 /o3tl/qa | |
parent | f0734deb7a3bcae2615adbe6a465ec39952b3e98 (diff) |
tdf#147861 ww8import: use GetFieldResult, not current DocProperty
In all the testing I could think of on DOCX and DOC examples
(and only a very few exist in the unit tests)
the actual value of the DocProperty was irrelevant to
what Word shows as the document loads.
It always takes the in-document, as-last-seen static text.
As a way to hack a fix using existing capabilities,
I marked as FIXEDFLD the unknown custom fields
that weren't handled separately.
That fixes what is displayed as the import value,
(which of course means that F9 will no longer
return a modification back to the DocProperty value).
It also means the (fixed) field is lost on export,
but a follow-up patch handles that for DOC/RTF/DOCX.
There were NO DI_CUSTOM examples in existing ww8 tests, but:
-ooxmlexport8: fdo74745.docx, fdo81486.docx
-ooxmlexport10: tdf92157.docx
and in these cases the plain text matched the variable anyway,
but a manual manipulation showed that LO is importing DOCX wrong
as well, so a similar import fix needs to happen for RTF/DOCX.
My fear is that there are some special-magic-associations
that worked properly the old way by accident that I will
break by marking them as fixed. No backporting please
since obviously very few people report bugs about fields.
Change-Id: I3f167eb3bd570b66ee829241bf9d31d557fc8749
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131237
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Diffstat (limited to 'o3tl/qa')
0 files changed, 0 insertions, 0 deletions