Why isn't there support for chemical drawing software in LibreOffice that enables round-trip editing?

Somehow, this had become a never-ending story for the Linux users; and I have just faced the truth as a quite new Linux user… However, I would like to ask this question one more time: is there ever going to be a functional plug-in or any other kind of support in LibreOffice that will enable existing chemical drawing softwares to be fully integrated into LibreOffice? I have already asked this question in the forum of my favorite chemical drawing software. According to those developers, LibreOffice does not provide such a functionality…

Do you think it is possible to create some kind of cooperation between the LibreOffice and chemical drawing software developers to finally end this “never-ending story”?

What exactly do you mean by chemical drawings?
You can use Math for chemical formulas.

You can also take a look at this extension: http://extensions.libreoffice.org/extension-center/chemistry

I have tried all of these extensions however none of them were functional enough and those extensions are not updated anymore… The biggest problem: they do not provide the “round-trip” editing functionality. I am looking for a “free-ware” chemical drawing software which provides the said functionality with high quality graphical results. However such a software does not exist at the moment. Oterwise I would not write this post…
As I said in my initial post, this a “never-ending story” for those who are in search of this functionality in Linux. My biggest hope is that: the LibreOffice developers finally would decide to cooperate one of those free-ware chemical drawing software developers and finally bring this functionality to LibreOffice and Linux… Is there a way to make developers to see this post?

Can you please edit your question to indicate both the prior round-trip you have used with satisfaction and the current (inadequate) round-trip methods you are using? Include detail about the OS, application names, file formats, and versions. Thanks.

I have used different versions of the Chem(Bio)Office, Accelrys Draw and Marwin Sketch with MS office… All of these softwares has great compatibility in Windows with MS office for round-trip editing.
Currently I am using Linux (xubuntu) and LibreOffice. Since Marwin Sketch is the most functional and the most comfortable chemical software (from the graphical point of view), I am using only Marwin Sketch in Linux. With LibreOffice in Linux, the only possibility to edit chemical drawings is exporting the Marwin Sketch structures as images (.png, .jpeg, .bmp, .svg …) and paste them into LibreOffice (which has generally resolution problems). When it is necessary to modify the drawings in LibreOffice document, it is required to find the related Marwin Sketch file in documents (if you did not forget to save it separately) , re-edit the structure and export it as a new image… A very time consuming process…
As I mentioned in my initial question, I have already ask the round-trip compatibility in Marwin Sketch forum and I indicated their opinion… Do you think LibreOffice developers are able to provide required functionality for chemical drawing software compatibility with round-trip editing? Can we make a request for such a development? Once it is done, I believe, LibreOffice will be the preferred word processing software of many users; especially who need chemical drawing functionalities in Linux environment.

Here is a very nice article discussing the “round-tirp” problem: http://depth-first.com/articles/2013/03/21/chemical-structure-copy-and-paste-problems/

It is very disappointing to know that the problem exists since 2007 and there is still no solution… I kindly ask everyone, who suffers from the same issue and looking for a solution to the problem, to join this conversation. I have strong belief that altogether, we could make LibreOffice developers to hear us!

I take it that you have tried BkChem ?

Yes, I have tried BkChem… But not satisfied…
Perhaps it would sound like I am very demanding; however I am looking for the same “round-trip” functionality that I experienced with MS office embedded, advanced chemical drawing softwares that I have used. And my question is whether it will ever be possible with LibreOffice.

Well, BKChem has been the best for me so far on Linux, and the ODG output can be edited directly in LO. I’ve fared far worse on OSX, where BKChem doesn’t appear to work very well because of the way OSX implements Python versions. On MS operating systems, you have full OLE support between the paid chemical drawing software and MS Office. LO’s OLE support is limited, and the LO clipboard doesn’t correctly recognize the image output formats that are available from the chemical drawing software.

No doubt, if the major chemical drawing software editors thought it worthwhile, we would already have equivalent “paid for” software on Linux, but apparently that is not the case, and this is not LO’s fault.

I would never blame LibreOffice for such a missing functionality. But I believe it is somehow possible to implement it… One of the commercial chemical drawing softwares has already enabled the round-tip editing in Linux and OpenOffice: http://www.chemdoodle.com/features/ (I am not using this software and I am not aware of the extent of its functionality).
So, as a great LibreOffice fan, I expect the same functionality in LibreOffice… There are many people in search of this functionality. I have read countless forums and blogs mentioning this missing functionality in Linux and open source word processing softwares. Maybe we should just let LibreOffice developers know what we want… Sometimes simple request make wonders :slight_smile:

I have really no programming or any related knowledge to discuss about the compatibility issues of the softwares and LibreOffice… However, I still can understand your point of view about OLE support…
Do you think Java based chemical drawing softwares could be the solution to the problem?

There are several extension in:

http://extensions.libreoffice.org/extension-center?getCategories=&getCompatibility=any&sort_on=positive_ratings&path=%2FLibreOffice-Extensions-and-Templates%2Fextension-center&portal_type=PSCProject&SearchableText=chemi*

http://extensions.services.openoffice.org/en/search?query=chemical&sort_by=field_project_stats_year&sort_order=DESC

Thanks for providing the extra detail, particularly the link to the article by Rich Apodaca. I now understand there is a difference between your definition of “round-trip” and the usual LO one (in terms of application). From the article:

The process of moving a chemical structure or drawing from a structure editor [external application] to a word processor [office suite] and back is called “round trip editing”.

This term is usually used in LO in relation to having an office document edited by application A (e.g., LO), then application B (e.g., MSO), then application A again. This is usually done using Microsoft file formats, but with MS Office 2013 can now be done more easily with ODF. The distinction is the editing of an entire compound file, rather than a single piece of that compound file.[1]

There is a special section of the OOXML specification (17.17.3) dedicated to Roundtripping Alternate Content. Again though, I doubt this applies to an expectation of cut / paste roundtripping (although it may). There does not appear to be an equivalent section in the ODF specification v1.2 for handling content not defined by the spec.[2] This may be the root cause of what you are experiencing.

[1] The idea of cutting and pasting an embedded object (e.g., drawing) back and forth between an office application and an external drawing application is (to me) a poor example of workflow. This is a workflow that Object Linking and Embedding (OLE) was specifically designed to solve.

[2] One particularly severe shortcoming of ODF is the lack of an open or ISO/IEC-approved object linking and embedding model. Microsoft OLE (the ODF spec references the 1995 work Inside OLE by Kraig Brockschmidt) is used in this respect. In late 2013 OASIS submitted a Referencing Explanatory Report (RER) about using this old work as a reference for ODF. Use of OLE will remain potentially problematic for interoperability until the OLE data structure spec (MS-OLEDS) is listed in the Open Specification Promise.

Thank you very much for the detailed explanation. Your answer was quite satisfying…
However, just to make sure, I would like to ask: does it mean that we should expect no “round-trip” editing functionality in a near future?
At last, could you please explain: do java-based softwares has the same OLE dependency for round-trip editing? Can it be achieved without OLE?

do java-based softwares has the same OLE dependency for round-trip editing? This is probably a beter answer than any I can give. I imagine there are other implementations. Can it be achieved without OLE? If OLE is not used, you are at the mercy of clipboard management (which applications do sporadically from what I can tell). I am not a fan of OLE but it is (reportedly) capable of handing off a blob of foreign content to an external app and retrieving the updated blob once the external app is done. I am less clear on how apps determine which of the various clipboards they use (perhaps this is actually clear and I just don’t know). does it mean that we should expect no “round-trip” editing functionality in a near future? I can’t answer this. It may be that either LO or the chem apps improve clipboard management or that a push is made by LO to improve OLE. I would have thought that BkChem would at least use an ODF-friendly clipboard, but again, I don’t know.

Not sure about BKChem’s clipboard format, but ChemDoodle claims to support Linux, OSX and Windows seamlessly. I will be trying ChemDoodle soon and if I like it at the end of the trial, will probably invest (as I need to simplify my workflow) on OSX. The big problem with LO on OSes that don’t use Windows OLE is the clipboard management - it is already suboptimal on OSX, and as there are too few devs working on OSX LO development, I can’t see this being a priority for them any time soon.