Created attachment 127406 [details] Table in custom-shape The <table:table> element is not allowed as child of a <draw:custom-shape>. For saving in extended ODF1.2 this was fixed in bug 84714 by using a <loext:table> in case of the <table:table> element. But in case of strict ODF1.2 this invalid element is still written. In addition this invalid table will be removed when the document is load. That is a bad user experience, because users do not know internals like ODF file format. They only notice, that their table is lost. How to reproduce: Load the attached document. Set your LibreOffice to save in strict ODF 1.2. Save a copy of the document. Look at the file source to see the invalid table. Reload the "strict ODF1.2"-document to see that the table is lost. [I'm not sure about the component.]
Repro. Used Tools - Options - Load/Save - General - ODF Format version: 1.2. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: 7da2f3ce9f7b049c177a735a146dae84a764d3f7 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-10-04_03:49:06 Locale: fi-FI (fi_FI); Calc: CL
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The error still exists in Version: 6.2.0.0.alpha1+ (x64) Build ID: f825e6d4082c0d0beb1c95b881f6a2ee9bfc9161 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-05_00:20:26 Locale: de-DE (en_US); Calc: CL The enhancement request to allow table in custom-shapes is in https://issues.oasis-open.org/browse/OFFICE-3761
Reading this one, I wonder if we shouldn't add a dialog indicating that since we use ODF 1.2 strict, some parts of the documents won't be exported so a backup should be made. Finally, block lines 1099 to 1139 from sw/source/filter/xml/xmltble.cxx should be executed only if we use odf version > 1.2 Any thoughts?
(In reply to Julien Nabet from comment #4) > Reading this one, I wonder if we shouldn't add a dialog indicating that > since we use ODF 1.2 strict, some parts of the documents won't be exported > so a backup should be made. The export to ODF 1.2 strict is only available via Tools > Options. So I assume, that users who switch to strict are advanced users. I think, that an additional dialog is not necessary. There is already the text "! Not using ODF 1.2 Extended may cause information to be lost." This could be extended by a hint to make a backup in 'extended' format. And perhaps a link to detailed information about 'strict' and 'extended'. There exists the page https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions. But that page is currently in such a bad state, that it is not helpful for users and not even helpful for developers. And the help [https://help.libreoffice.org/Common/General_7] has only one example about a feature, which does not exist in 'strict'. Improvement in that area would be a different issue. > Finally, block lines 1099 to 1139 from sw/source/filter/xml/xmltble.cxx > should be executed only if we use odf version > 1.2 > Any thoughts? Why do you think so? The <office:dde-source> element exists already in ODF 1.1.
(In reply to Regina Henschel from comment #5) > ... > > Why do you think so? The <office:dde-source> element exists already in ODF > 1.1. You're right, forget my last comment.
The error still exists in Version: 6.4.0.0.alpha0+ (x86) Build ID: 2ef2c031ce9ec730b13fca8bca808f382aab5fe4 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: CL It would be possible to use in ODF 1.2 strict a construction like this: Write a <draw:frame> as child of a <text:p> element and then the <table:table> element as child of the frame.
> It would be possible to use in ODF 1.2 strict a construction like this: Write a <draw:frame> as child of a <text:p> element and then the <table:table> element as child of the frame. while that would technically be valid according to the schema, i find it misleading: a frame element suggests that the table is itself a floating entity, but in the attached bugdoc it's clearly inline in the text. using as-character anchor would also be misleading because it's not inside a paragraph.
oh, btw i can't reproduce a table:table element being written in strict ODF 1.2, it's a loext:table but there's no declaration of loext namespace
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d705a860936a58e40a2894a12d02be585a06e1c1 tdf#102256 sw: ODF export: don't write table:table in shapes It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed on master
If the document is saved in "ODF 1.3 strict" the table element is removed, but the following paragraph gets the attributes table:name="Table1" table:style-name="Table1"
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/316d68416dfee64d54ecaa4839a4045a4f205c4d tdf#102256 sw: ODF export: oops, don't write table attributes ... It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://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-7-0": https://git.libreoffice.org/core/commit/b8403f48b68b64e05a0c50578b8bde67b300c783 tdf#102256 sw: ODF export: oops, don't write table attributes ... It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
sorry that was a dumb mistake, should be fixed now
Test OK in Version: 7.0.0.0.beta1+ (x64) Build ID: f92220b73d971e9d760c545efd60179ad1b6902a CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL and in Version: 7.1.0.0.alpha0+ (x64) Build ID: 83c4f86f22dc37269ac6a038fe7de053c42aad6e CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL