Created attachment 107420 [details] <table:table> in <draw:frame>, valid but not supported. ODF1.2 allows a <table:table> element as direct child of a <draw:frame> element. See http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html Section 9.1.2 <table:table> and 10.4.2<draw:frame> Currently LibreOffice writes <table:table> as child of <draw:text-box> or as sibling of <text:p>. This leads to problems, when using a table in a shape with added textbox. Currently the <table:table> element is written as child of <draw:custom-shape>. But that is invalid. <table:table> can not be a child of <draw:custom-shape>. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-draw_custom-shape. But a <text:p> element is allowed as child of <draw:custom-shape> and of other shapes as well. See the list of valid parents of <text:p> in http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_p And on the other hand the <text:p> element can have a <draw:frame> child. So a valid storage of a table in a textbox added to a shape would be: <draw:custom-shape> ... <text:p> <draw:frame> <table:table> ... </table:table> </draw:frame> </text:p> ... </draw:custom-shape> That would be the same way, currently <draw:object> elements (for Math-OLE) and <draw:image> elements are used in this textbox in a shape. Unfortunately, LibreOffice does not accept <table:table> as direct child of <draw:frame> and drops it when it reads such a file. Try attached document. Calligra Words and Softmaker Textmaker can at least read files with <table:table> as child of <draw:frame>.
Isn't it possible that ODF doesn't allow <table:table> inside <draw:custom-shape> because ODF is based on OOoXML, and in OOo's codebase, the contents of draw:custom-shape had to be always rendered by editeng, which is not capable of doing that? If so, I think it would be better to file a proposal at OASIS to allow table:table inside draw:custom-shape. I agree that in the meantime, we should not write table:table as a child of draw:custom-shape, e.g. we could write loext:table instead, till the proposal is accepted. How does that sound? Adding fake paragraphs and frames to ODF, which is our #1 format sounds like a bad idea to me.
This request goes beyond the example to use it for the textbox in shapes. Here another use case: There exists already the structure <draw:frame><table:table>...</table:table></draw:fame> in a Draw document, when you insert a table in a Draw document. If you currently copy such table and paste it into a Writer document, you can get the table as image or as OLE but not in "Drawing format", because Writer does not support this structure.
(In reply to Miklos Vajna from comment #1) > I agree that in the meantime, we should not write table:table as a child of > draw:custom-shape, e.g. we could write loext:table instead, till the > proposal is accepted. How does that sound? I have ask in AOO-dev. There is no strong preference for one solution. Armins answer from a development point of view might be interesting for you. http://markmail.org/message/dimqg5pktyngizjg
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62391c28fae5099dd1f67c322867933fcb05bc9f fdo#84714 ODT import: read <loext:table> inside <draw:custom-shape> It will be available in 4.5.0. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4de5b40eb7220da2d337eb98d7905a98dc12c72 fdo#84714 ODT export: write <loext:table> inside <draw:custom-shape> It will be available in 4.5.0. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4f907edbc1f6ce375bbf71c44733bb85f67a74f&h=libreoffice-4-4 fdo#84714 ODT import: read <loext:table> inside <draw:custom-shape> It will be available in 4.4.1. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e15e4d3888c1ebd229acd8e676d28115edf622e3&h=libreoffice-4-4 fdo#84714 ODT export: write <loext:table> inside <draw:custom-shape> It will be available in 4.4.1. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0657176b3e42886c4ae14f9991c52b4d61bbe116&h=libreoffice-4-4 fdo#84714 SwTextBoxHelper::findTextBoxes: optimize unnecessary O(n^2) It will be available in 4.4.1. 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.
I have written a bug 102256 as follow-up report, because this only fixes the problem for saving in ODF 1.2 extended, but not for saving to strict ODF 1.2.