To demonstrate the issue open the attached Word document in LibreOffice. The document contains an input field. Next, save the document as ODT. Now open the resulting ODT file in OpenOffice.org (not LibreOffice). Result: The input field is gone (though the default text inside remains). This problem does not exist if you follow the same steps (open DOC, save as ODT, open in OOo) with OpenOffice.org, so it is a LibreOffice-specific bug. The underlying problem is that in this case LibreOffice uses fieldmarks (see http://wiki.oasis-open.org/office/Fieldmarks) to save the input fields in the ODF document ("vanilla" OOo uses normal input fields when importing from DOC). Since fieldmarks are not part of the ODF 1.2 standard other ODF implementations (like OpenOffice.org) don't understand them. I'm working in a large administration migrating from MS Office to OpenOffice and for us this bug is a major problem (in fact a blocker for a possible adoption of LibreOffice) because we have a huge amount of MS Office documents containing input fields. Our usual workflow is to open these documents with OpenOffice, edit them and then save them as ODF. But this bug means that we can't use LibreOffice like that because all input fields will be lost. But even besides our specific needs it should not be deemed acceptable by the Document Foundation that LibreOffice produces non-standard ODF which can't be interpreted correctly by OpenOffice.org.
Created attachment 39289 [details] document containing an input field
This is an advanced feature and there is an enhancement proposal on the ODF side. Change the ODF version in the options to 1.2 Strict and the field will simply not be saved in the ODT file. Closing as not a bug. Feel free to reopen if needed.
Let me give a bit more background information around this extended ODF feature. OASIS (and most other standardization entities) will only standardize what has been implemented - in the case of OASIS, at least three independent implementations are required (http://www.oasis-open.org/committees/change_summary_2002.php, section "Section 2 Standards Process"). So it's standard practice to implement new features, and submit them to OASIS doing so - for the extended fieldmark stuff, this can be found here: http://wiki.oasis-open.org/office/Fieldmarks. The new feature then undergoes review, and potential refinement, in the technical committees - for the fieldmarks, the decision was to move them to ODF-Next, i.e. past ODF 1.2. So clearly, having new features implemented *while* standardization is in progress is necessary, even unavoidable to actually *have* something standardized in the end. This has also happened for a number of _vanilla OpenOffice.org features_, a few examples (not exhaustive) are: * annotations in Impress * Sheet events for StarBasic in Calc * extended Chart positioning ODF 1.2 permits that, under non-ODF namespaces, in the so-called extended conformance class. OpenOffice.org and LibreOffice both default to saving *with* those extensions, to not loose features, and facilitate roundtripping. If this is not desired, please change the ODF compatibility level, as Cedric already advised.
@Cédric: With which build did you try your workaround? I tried with the LibreOffice Beta1 for Windows and setting the ODF version to 1.2 (not extended) did NOT change the behaviour of LibreOffice. It still saves the fieldmarks, vanilla OOo still can't read them and loses the input field. So, this is not a solution and I will reopen the bug. @Thorsten: Thank you for the explanation, but as said above the problem exists even when using ODF 1.2 Strict. But even if it didn't I think LibreOffice should at least generate a warning message when using features that are not part of the standard. Using a setting as the default value which in a very simple and common use case (opening Word files and saving them as ODF) produces documents that can't be correctly read by all users of vanilla OOo is not good.
Sorry, I forgot that I recently fixed this in Go-oo and forgot to migrate the patch to LibreOffice. The problem is now fixed by commit: http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=d288cef69056f123377d288a49d7ed8f1563ad0f
@Cédric: you wrote that If I use the save option "ODF 1.2 Strict", then there will be no information about the fieldmarks at all in the saved ODF-file. So I loose information. Wouldn't it be correct to store the best matching information regarding to ODF 1.2 instead (which should be an input-field information that could be recognized by OOo) Just thinking about mapping-tables as also used by e.g. the microsoft implementation of odf.
@Christoph, One point for you :) The problem is that is will need some additional work and I don't know when I'll have time for it. There are several types of fieldmarks to handle: * Text fields * Check boxes * List boxes * Unhandled fields I'll try to fix that ASAP, but I'ld be more than happy to help someone hack into xmloff/source/text/txtparae.cxx: it shouldn't be a hard hack to start with. Reopening the bug.
A few more code pointers for the ones who want to have a go at this easy hack: The code is located in XMLTextParagraphExport::exportTextRangeEnumeration() method in file xmloff/source/text/txtparae.cxx. In this method, when sType equals sTextFieldStart, sTextFieldStartEnd, sTextFieldEnd, some enhanced ODF is written when saving in ODFVER_LATEST. The equivalent ODF 1.2 strict controls should be written here.
back to the pool as it's an easy hack
I am working on this bug, will hopefully have a patch done in the next few days.
Removed EASYHACK from summary
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4190e9351e69730f0097e6cdf4dad2fafa10577e fdo#30711: fix some problems in 7a1c5e54:
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=01ef7d0c5c6e3ea746a3661c7e3498027ca62291&g=libreoffice-3-6 fdo#30711: fix some problems in 7a1c5e54: It will be available in LibreOffice 3.6.0.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=22b615a7a54e6424bf3a492d2a07573ad9090949 fdo#30711: ODF export: "text:name" is mandatory on bookmarks: The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ec272a7608ba006573540b4bb8812c01a930d09e&g=libreoffice-3-6 fdo#30711: ODF export: "text:name" is mandatory on bookmarks: It will be available in LibreOffice 3.6.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
LibreOffice 4.2.0.2 on Windows with "ODF 1.2 strict" compatibility saves odf without field name. So, if you have field named "Field1" in doc, open it in LO, save to odt, and get input field with empty hint and content = "Field1" The same if document saved in .doc, word doesn't display any field name.
Migrating Whiteboard tags to Keywords: (EasyHack) [NinjaEdit]