summaryrefslogtreecommitdiff
path: root/libreofficekit
diff options
context:
space:
mode:
authorJustin Luth <justin.luth@collabora.com>2023-12-01 14:16:14 -0500
committerMiklos Vajna <vmiklos@collabora.com>2023-12-05 08:48:38 +0100
commitcaecfff1adbe9715260ef9e2009333e523d61123 (patch)
tree5e14c82091a7a44318c3183a58d730ef385bfe43 /libreofficekit
parent9c02160fc55bccc43d92c68ec5166a79d50e1528 (diff)
tdf#108505 writerfilter: fix field direct char settings
Instead of adding characters properties one at a time, lets take care of everything all at once. The results seem to be good so far. There is even some similarity between how MS Word has these properties on the "in-between" pseudo end character, where placing the cursor after the field gets these properties. I don't see it happening in MS Word at the pseudo start character, but it does in LO now... Hopefully that doesn't end up doing bad things. In the unit test, replacing the content ends up in red, italic. However, I see the same thing in MSO when testing with my second FORMTEXT example, so I think everything is "working as expected". I tried to see if I could limit doing this for only certain types of fields or conditions. However, pContext->GetResult() doesn't have a \fldrslt yet at the time this is happening. Also, TextField.is() happens less than I expected. I'm sure I could limit it to just certain pContext->GetFieldId(), but so far no problems are noticed for all field types. make CppunitTest_sw_rtfexport6 \ CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat make CppunitTest_sw_rtfexport6 \ CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat2 Change-Id: I3223437fd0d694f5e5733a9f7323f10f03d7802f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160232 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Diffstat (limited to 'libreofficekit')
0 files changed, 0 insertions, 0 deletions