Created attachment 115706 [details] Bern Canton forms feedback We receive from our cantonal authority the following form to be filled. The document is publicly available at http://files.be.ch/bve/agi/geoportal/geo/zip/UP5/UP5_Umfrage.docx (attached for convenience) Opening in writer is proposed first in read only mode, clic on edit document still make it unsable Format of first page is totally lost Checkbox and radio button are not working. Opening this document with a 2013 MS-Office works as expected (see attached pdf resulting) Tested with 4.4.3.2 under Linux and Windows
Created attachment 115709 [details] Export of the document by Loo 4.3.6.2 under windows
Created attachment 115710 [details] Export of the document by MS-Office 2013 See the difference with the header and footer Also the first page layout
Checkbox/radio button under any Loo version are like a picture block ? compared to the expected behavior
I can confirm with LO 4.4.3, win7
*** Bug 92569 has been marked as a duplicate of this bug. ***
The wrong layout on the first page has more than one reason: - The table in the header is composed of conditional fields that are not evaluated. That results in duplicated entries. - The section properties contain a "<w:type w:val="continuous"/". But they are wrongly interpreted as page break - The page break <w:r w:rsidRPr="00A67D85"> <w:br w:type="page"/> </w:r>" before the table of contents is ignored.
(In reply to Oliver Specht from comment #6) > - The section properties contain a "<w:type w:val="continuous"/". But they > are wrongly interpreted as page break Is it Bug 64372? And numbering problem, so "4 Fragebogen und Planausschnitte" starts from 1. Couldn't find a reported bug. Also, I don't understand why checkbox and radio button are not working in this file.
(In reply to Timur from comment #7) > (In reply to Oliver Specht from comment #6) > > - The section properties contain a "<w:type w:val="continuous"/". But they > > are wrongly interpreted as page break > Is it Bug 64372? Seems to be the same problem. > > And numbering problem, so "4 Fragebogen und Planausschnitte" starts from 1. > Couldn't find a reported bug. I can't answer that. The .docx uses the same "<w:numId w:val="1"/>" while the .odt applies WWNum17 to the first headings while the next use WWNum1 > > Also, I don't understand why checkbox and radio button are not working in > this file. They are imported as pictures. The source is a composition of a control and a shape: <w:object w:dyaOrig="225" w:dxaOrig="225"> <v:shape id="_x0000_i1157" type="#_x0000_t75" o:ole="" style="width:108pt;height:20.5pt"> <v:imagedata o:title="" r:id="rId65"/> </v:shape> <w:control r:id="rId66" w:name="OptionButton14" w:shapeid="_x0000_i1157"/> </w:object>
I reported numbering problem as Bug 94819. žAs for what the bug is about, form controls, this was never OK. OO 3.3 couldn't show it at all. LO 3.3 shows at least some of them, but similarly as now.
*** Bug 99571 has been marked as a duplicate of this bug. ***
*** Bug 102243 has been marked as a duplicate of this bug. ***
As Oliver mentioned in comment 8, each control has two parts. The first is a fallback WMF image for apps that arent able to handle the actual ActiveX control and this is what LibreOffice is displaying and the second is the ActiveX control that <w:r> <w:object w:dxaOrig="225" w:dyaOrig="225"> <v:shape id="_x0000_i1123" type="#_x0000_t75" ... o:ole=""> <!-- fallback image start --> <v:imagedata r:id="rId31" o:title="" /> <!-- fallback image end --> </v:shape> <!-- activeX control start --> <w:control r:id="rId32" w:name="CheckBox4" w:shapeid="_x0000_i1123" /> <!-- activeX control end --> </w:object> </w:r> And you can see the relationship IDs for these parts in the /word/_rels/document.xml.rels file <Relationship Id="rId31" ... Target="media/image9.wmf" /> <Relationship Id="rId32" ... Target="activeX/activeX8.xml" />
In order for this to be resolved, LO would have to be able read/parse the Microsoft Office Forms Binary Format, which is used by activeX form controls. https://msdn.microsoft.com/en-us/library/office/cc313125(v=office.12).aspx http://interoperability.blob.core.windows.net/files/MS-OFORMS/[MS-OFORMS].pdf
@Tamas: Do you have a file parser for the activeX binary files or are you planning to write one yourself?
(In reply to Yousuf Philips (jay) from comment #14) > @Tamas: Do you have a file parser for the activeX binary files or are you > planning to write one yourself? LibreOffice already has a parser for this binary. PPTX and XLSX import of activeX controls used to work earlier. I made it to work again: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c8e3633a352c2fda3aebb9781288a926e7a88c42 The parser of the binary file is in oox/source/ole/axcontrol.cxx. We need to make this code triggered also for DOCX import.
(In reply to Tamás Zolnai from comment #15) > LibreOffice already has a parser for this binary. PPTX and XLSX import of > activeX controls used to work earlier. I made it to work again: > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=c8e3633a352c2fda3aebb9781288a926e7a88c42 > > The parser of the binary file is in oox/source/ole/axcontrol.cxx. We need to > make this code triggered also for DOCX import. Thanks for the info and taking this on. :D
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a764319cbad4e2589cc105145ac27defbf49ff6 tdf#91384: DOCX: import ActiveX controls It will be available in 6.0.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.
This DOCX attachment 115706 [details] verified. Note: turn off design mode first. But DOCX attachment 117075 [details] from Bug 92569 and attachment 126130 [details] from Bug 99571 not, why? Also not DOCM attachment 127385 [details] from Bug 102243. Can you fix them also or to set back as New?
Actually, attachment 115706 [details] also has problem similar to problem: radio group should be mutually exclusive, but when you select first, and then second and subsequent, previous ones stay selected.
Actually, attachment 115706 [details] also has problem similar to attachment 127385 [details]: radio group should be mutually exclusive, but when you select first, and then second and subsequent, previous ones stay selected.
(In reply to Timur from comment #18) > This DOCX attachment 115706 [details] verified. Note: turn off design mode > first. > But DOCX attachment 117075 [details] from Bug 92569 and attachment 126130 [details] > [details] from Bug 99571 not, why? > Also not DOCM attachment 127385 [details] from Bug 102243. > Can you fix them also or to set back as New? So(In reply to Timur from comment #18) > This DOCX attachment 115706 [details] verified. Note: turn off design mode > first. > But DOCX attachment 117075 [details] from Bug 92569 and attachment 126130 [details] > [details] from Bug 99571 not, why? > Also not DOCM attachment 127385 [details] from Bug 102243. > Can you fix them also or to set back as New? Hi Timur, I see a bunch of different bugs are marked as duplicate. This bug was about ActiveX checkbox and radio button. In MSO there more types of controls. I'll reopen the different bugs.
(In reply to Timur from comment #18) > This DOCX attachment 115706 [details] verified. Note: turn off design mode > first. > But DOCX attachment 117075 [details] from Bug 92569 and attachment 126130 [details] > [details] from Bug 99571 not, why? > Also not DOCM attachment 127385 [details] from Bug 102243. > Can you fix them also or to set back as New? So I reopened two bugs, which has a test document with different controls in them. The DOCM file you mentioned here is opened nicely for me. Radio buttons can be edited.
(In reply to Timur from comment #20) > Actually, attachment 115706 [details] also has problem similar to > attachment 127385 [details]: > radio group should be mutually exclusive, but when you select first, and > then second and subsequent, previous ones stay selected. Yeap, it's a bug, which would be good to fix. I opened a new bug for this (Bug 111980), since this bug was about checkbox and radio button were imported as pictures. It's easier to work on a separate bug, if an other developer want to pick this up.