Created attachment 204735 [details] fielddemo.odt (see steps to reproduce) When a document is saved as .html, any "field" references show with a dark background when the .html is viewed in a browser (similar to how they look in LO when editing). The generated html includes custom tags which allow LO to recognize field references if the .html file is re-imported later (e.g. for more editing). The dark background is unnecessary, and I think it causes an unintended direct character format to be introduced when the .html is re-read. The generated html looks like this: <span style="background: #c0c0c0"> <sdfield type=DATETIME sdnum="1033;1033;MMMM D, YYYY"> December 19, 2025 </sdfield> </span> STEPS TO REPRODUCE: 1. Create a Writer document with a field reference, for example Type "Today's date is" then Insert->Field->Date(Variagble) -OR- Load the attached "fielddemo.odt" 2. File->SaveAs, set the file type to "HTML DOcument (Writer)(.html); click Save 3. Examine the resulting .html file 4. firefox file.html # view the result in a browser RESULTS: The field value has a dark background when the .html file is deployed. EXPECTED RESULTS: No background color (unless the user explicitly formatted the text with a background color in LO).
Confirm with Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 7cbc16bf6e115d2aaabe9b9b20edd66a5c597571 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded but not with Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-6.3. a43e0743d34c4c3c18091f6bf1f2afefe24723e0 is the first bad commit commit a43e0743d34c4c3c18091f6bf1f2afefe24723e0 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Mar 12 16:58:08 2019 +0100 source 507ac9b8c20926de7479213cf2d890bbb5952a1d 69081: sw HTML export: handle field shadings view option | https://gerrit.libreoffice.org/c/core/+/69081 Not a bug. You can disable field shading in View > Field Shadings
> Not a bug. You can disable field shading in View > Field Shadings Isn't that for controlling shading in the LO editing view? Field *values* should not ever be shaded in output presentations, it seems to me. If sitting output is intended, then why doesn't it cause fading in PDF or print?
Meant "shading" not 'sitting' or 'fading'. I so much enjoy typing on a phone...
(In reply to Jim Avera from comment #3) > > Not a bug. You can disable field shading in View > Field Shadings > > Isn't that for controlling shading in the LO editing view? Field *values* > should not ever be shaded in output presentations, it seems to me. > > If sitting output is intended, then why doesn't it cause fading in PDF or > print? That's a question for Miklos, who implemented this feature.
There was a debate if these shading should be exported to HTML or not. It depends on what's your intent with the HTML export. If you want to view the HTML and expect to see no differences from the normal Writer edit window, then you want those shading on. If you want to print that HTML later, you probably want it similar to the PDF export where these are not on. As a compromise, the best seemed like to make this configurable, so everyone can have what they want. So yes, the current behavior of not losing the shading when you have the shading option enabled is intentional.