Hello, I am using the following version of LibreOffice: Version: 5.0.6.2 Build ID: 1:5.0.6-0ubuntu1 Locale: de-DE (de_DE.UTF-8) My OS is Ubuntu 15.10. I am a developer and maintainer of the DokuWiki ODT plugin (also see https://www.dokuwiki.org/plugin:odt). I am facing a problem in LibreOffice Writer: If I embed a table in a text box then the table disappears when I open the exported document in LibreOffice. Exported means converted from Wiki text to ODT format using the DokuWiki ODT plugin. If I look at the XML content then I can see that the entire table:table element has been deleted. If I do not include the table in a text box - just directly on the page - then it is displayed. Exactly the same table. I compared the exported document with a document created in LibreOffice showing a table in a text box. But I could not find the reason for the problem. I also tried to get some log files but did not find anything meaningful. So far I did not debug LibreOffice (I guess that would be very complex to find the right place to look at if you are debugging it for the first time). Anyway, I still would like to find the problem on my own, especially because it could of course be a issue in my code. Is there a way of enabling error or log messages especially for situations in which LibreOffice doesn't like the XML coding of an opened document? Or are you aware of common encoding problems when placing a table in a text box? Thanks in advance. Best Regards, LarsDW223
Created attachment 127247 [details] Original ODT document as exported by DokuWiki ODT plugin This is the original ODT document as created by the DokuWiki ODT plugin. You can see the included table:table element in the frame/text-box. As soon as I open this document in LibreOffice Writer, the table will be deleted. The frame/text-box and the paragraph that I included after the table will still be there. Only the table is deleted. As mentioned before: if I place exactly the same table outside of a frame/text-box then everything will be fine.
I don't believe a Text box draw object can hold a table. Believe you'd need to use a Frame object. @Regina, any code pointers?
Created attachment 127248 [details] Same table, this time only in a frame (no text box)
@V Stuart Foote: Yes, of course you are right. A text box can not hold a table. LibreOffice itself is deactivating the menu items for tables if I place the cursor in a text box. Sorry, I got confused - tested to much variations. The last attachment shows the same table only in a frame - no text box. In this case the complete frame is deleted, resulting in an empty document (just an empty paragraph).
I found some problems on my side: 1. faulty XML encoding caused through a re-design of my plugin 2. the table needs to be in a text box 3. the frame needs to have a "graphic" style assigned which needs to have the attribute 'style:parent-style-name="Frame"' 4. graphic style "Frame" must exist as a common style in styles.xml 5. the frame and text box may not be surrounded by a "<draw:g>" element Point 1 is clearly my fault. Points 2 to 5 are hard to know cause this things do not seem to be documented in the ODF standard. Is there a documentation about such correlations somewhere? Also point 2 is quite strange because of the following facts: - In the LibreOffice GUI I can open a frame and place a table in it. That will be actually encoded as a "<table:table>" inside a "<draw:text-box>" inside a "<draw:frame>" - In the LibreOffice GUI I can open a text-box. But in that case I can not place a table in it. The menu options for inserting a table are inactive. So, I think we can close this now. But it would be great if someone could point me to some more in-depth documentation of ODF or LibreOffice ODF encoding in case that this encoding/behaviour is LibreOffice specific.
The standard allows more than is implemented in LibreOffice. You can use the Relax NG Schema http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-schema.rng to see the allowed nesting. But it might be, that the standard itself makes additional restrictions. There exists the controversy issue https://issues.oasis-open.org/browse/OFFICE-3761 for a table as direct child. In the schema you will find, that from all kind of "shape-instance" only "draw-frame" can have a "draw-text-box" and only this is able to carry a table. "draw-g", draw-page-thumbnail, "draw-control" and "dr3d-scene" have nothing of that kind and the others only a "draw-text" and latter can only have "text-p" and "text-list". From point of standard a solution can be to put a <draw:frame> into a <text:p> and then a <table:table> into <draw:frame>. But that does not help you with LibreOffice, because it is not implemented. The current solution of LibreOffice, to allow <table:table> in a custom-shape in Writer produces an invalid file, if saved in strict ODF1.2; and therefore on opening the table is removed. In case you use 'ODF1.2 extended' when saving, than it will be written as <loext:table> and the table still exists after opening. Why do not use that construct, that is called a "Frame" in the UI? For that shape the full <draw:text-box> features are implemented for Writer.
I will use the method which the UI calls a "Frame" in my plugin, thanks. I was just wondering that if it is actually encoded as a text-box in a frame then why is there a difference in the UI between the UI options "Frame" and "Text-Box" if both is encoded as a text-box in a frame. I am also aware of the relaxNG schema and I think I can understand the structure description (which elements may have which childs, also this is described very good in the ODF1.2 standard with all it's links between the sections). What I think is not described in the standard/relaxNG schema is the requirement that the frame needs to have a graphics-style assigned which needs to have the attribute 'style:parent-style-name="Frame"'. Otherwise the frame/text-box with a table will not be displayed in LibreOffice. Or is this kind of relation in the standard/relaxNG schema and I did'nt see it? But anyway thanks for your reply. I now know what to do (I think) and so we should close this. Thanks.
So I consider this as support request and will close it. Please use a new bug in case you want to report a real bug or have an enhancement request.