Bug 30711 - LibreOffice saves input fields in a non-standard ODF way
Summary: LibreOffice saves input fields in a non-standard ODF way
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium critical
Assignee: Brennan Vincent
QA Contact:
URL:
Whiteboard: target:3.6.0 target:3.7.0
Keywords: easyHack
Depends on:
Blocks:
 
Reported: 2010-10-08 08:55 UTC by Daniel Benkmann
Modified: 2015-12-18 09:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
document containing an input field (23.00 KB, application/msword)
2010-10-08 08:56 UTC, Daniel Benkmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Benkmann 2010-10-08 08:55:17 UTC
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.
Comment 1 Daniel Benkmann 2010-10-08 08:56:28 UTC
Created attachment 39289 [details]
document containing an input field
Comment 2 Cédric Bosdonnat 2010-10-08 10:05:13 UTC
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.
Comment 3 Thorsten Behrens (CIB) 2010-10-08 11:55:23 UTC
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.
Comment 4 Daniel Benkmann 2010-10-11 11:50:15 UTC
@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.
Comment 5 Cédric Bosdonnat 2010-10-12 01:26:00 UTC
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
Comment 6 Christoph Lutz 2010-10-13 00:59:48 UTC
@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.
Comment 7 Cédric Bosdonnat 2010-10-13 02:06:58 UTC
@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.
Comment 8 Cédric Bosdonnat 2010-10-28 07:25:05 UTC
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.
Comment 9 Cédric Bosdonnat 2011-02-11 07:55:00 UTC
back to the pool as it's an easy hack
Comment 10 Brennan Vincent 2012-04-05 14:04:07 UTC
I am working on this bug, will hopefully have a patch done in the next few days.
Comment 11 Florian Reisinger 2012-05-18 08:19:08 UTC
Removed EASYHACK from summary
Comment 12 Not Assigned 2012-06-05 05:04:54 UTC
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:
Comment 13 Not Assigned 2012-06-05 05:16:29 UTC
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.
Comment 14 Not Assigned 2012-09-14 13:08:55 UTC
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.
Comment 15 Not Assigned 2012-09-17 07:58:00 UTC
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.
Comment 16 gma 2014-02-22 05:14:02 UTC
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.
Comment 17 Robinson Tryon (qubit) 2015-12-18 09:55:47 UTC
Migrating Whiteboard tags to Keywords: (EasyHack)
[NinjaEdit]