Created attachment 44012 [details] Form with tick boxes as Microsoft .doc, with boxes ticked When filling in a Word form which includes tick boxes, LibreOffice writer keeps the information which boxes have been ticked when saving as ODF, and re-opering the ODF file. However, when saving as Microsoft .doc, Writer looses the information, and it also does not import it when opening from .doc. This worked in OOO330m19 (rc2), but does not work in the released version of 3.3.1 (using Debian packages from unstable). In both version, LibreOffice Writer does not register a change to the file when just changing a tick - the "Save" button remains greyed out, as does the menu entry, and the change has to be saved using "Save as". I attach the same file as ODF and .doc, in both cases the tick boxes are ticked: 1. Page 1: "Management" is ticked 2. Page 2: "Confidential" is ticked and "Other" is ticked
this is fixed in the master and should be 3.3.2 ( except for the document change isn't registered ) - I will investigate that
marking as fixed ( now document is marked as modified when changing the checkbox )
ah I see that the checkbox writing fix does actually exist in 3.3.1 just the document getting marked modified is the problem
(In reply to comment #3) > ah I see that the checkbox writing fix does actually exist in 3.3.1 just the > document getting marked modified is the problem Well, I have 3.3.1 on my computer at home, where I have the reported problem (both of them), and rc2 at work (avoided upgrading once I noticed). Maybe it's a problem with the debian packages only, but when I upgraded from rc2 to 3.3.1 at home it stopped writing the checkbox ticks...
(In reply to comment #4) > (In reply to comment #3) > > ah I see that the checkbox writing fix does actually exist in 3.3.1 just the > > document getting marked modified is the problem > > Well, I have 3.3.1 on my computer at home, where I have the reported problem > (both of them), and rc2 at work (avoided upgrading once I noticed). Maybe it's > a problem with the debian packages only, but when I upgraded from rc2 to 3.3.1 > at home it stopped writing the checkbox ticks... can you check again and report back? ( I just verified again with the 3.3.1 from libreoffice download ) But... I doubt this would be a problem with the debian packages. Always worth checking too if some strange problem with user configuration ( although doubtful ) might be causing a problem. To check that you might just move away your libreoffice config directory and restart libreoffice ( this will force a new config directory to be generated ) e.g. mv ~/.libreoffice ~/.libreoffice.old
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > ah I see that the checkbox writing fix does actually exist in 3.3.1 just the > > > document getting marked modified is the problem > > > > Well, I have 3.3.1 on my computer at home, where I have the reported problem > > (both of them), and rc2 at work (avoided upgrading once I noticed). Maybe it's > > a problem with the debian packages only, but when I upgraded from rc2 to 3.3.1 > > at home it stopped writing the checkbox ticks... > can you check again and report back? ( I just verified again with the 3.3.1 > from libreoffice download ) But... I doubt this would be a problem with the > debian packages. Always worth checking too if some strange problem with user > configuration ( although doubtful ) might be causing a problem. To check that > you might just move away your libreoffice config directory and restart > libreoffice ( this will force a new config directory to be generated ) > > e.g. mv ~/.libreoffice ~/.libreoffice.old I did as suggested, and opened the attached file with LibreOffice-3.3.1 at home (after moving the configuration). It does show the boxes, but all empty - which is what I expected. I have: LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2, Debian package 1:3.3.1-1 As said before, it works fine with the rc2 packages at work, and it did at home before upgrading to the 3.3.1 released version.
(In reply to comment #6) [...] > I did as suggested, and opened the attached file with LibreOffice-3.3.1 at home > (after moving the configuration). It does show the boxes, but all empty - which > is what I expected. hold on, didn't you say that it was just saving the .doc ( as .doc ) with modified check boxes was the problem ? e.g. the modifications weren't preserved? Are you saying there are 2 problems? a) opened .doc file has unchecked checkboxes b) saving changed checkboxes fails is that correct? Just to check we are on the same page what I do is open the attached document what I see is as follows.. 1. Page 1: "Management" is ticked 2. Page 2: "Confidential" is ticked and "Report" is ticked ( and not 'Other' as you stated ) I check all the boxes on Page 1 and save as ( newfilename.doc ) and close and reopen the newfilename.doc. all the checkboxes are checked as expected can you try again also please attach the 'newfilename.doc' you get after checking the boxes. one more thing could you attach a screen shot of the problematic attached .doc opened in writer ( just the first page )
(In reply to comment #7) > (In reply to comment #6) > [...] > > I did as suggested, and opened the attached file with LibreOffice-3.3.1 at home > > (after moving the configuration). It does show the boxes, but all empty - which > > is what I expected. > hold on, didn't you say that it was just saving the .doc ( as .doc ) with > modified check boxes was the problem ? e.g. the modifications weren't > preserved? > > Are you saying there are 2 problems? > a) opened .doc file has unchecked checkboxes > b) saving changed checkboxes fails > > is that correct? I didn't try b) - as on the same computer I either only have 3.3.1-rc2 (which works for me), or 3.3.1 (which does not work for me). When I save from 3.3.1, and re-open, the boxes are no longer ticked. But also, opening the attached file with 3.3.1 did not show the boxes ticked (for me), which suggests that at least opening is a problem. Saving might be - but I didn't check that yet. > > Just to check we are on the same page what I do is > > open the attached document what I see is as follows.. > 1. Page 1: "Management" is ticked > 2. Page 2: "Confidential" is ticked and "Report" is ticked ( and not 'Other' as > you stated ) correct > > I check all the boxes on Page 1 and save as ( newfilename.doc ) and close and > reopen the newfilename.doc. all the checkboxes are checked as expected This works for me with 3.3.1-rc2, but not with 3.3.1. I can only check again once I'm back home. > > can you try again also please attach the 'newfilename.doc' you get after > checking the boxes. > > one more thing could you attach a screen shot of the problematic attached .doc > opened in writer ( just the first page ) Will do so, hopefully tonight. But if it works for, then maybe it is a Debian problem?
> > I check all the boxes on Page 1 and save as ( newfilename.doc ) and close and > > reopen the newfilename.doc. all the checkboxes are checked as expected > This works for me with 3.3.1-rc2, but not with 3.3.1. I can only check again > once I'm back home. > > > > can you try again also please attach the 'newfilename.doc' you get after > > checking the boxes. > > > > one more thing could you attach a screen shot of the problematic attached .doc > > opened in writer ( just the first page ) > > Will do so, hopefully tonight. But if it works for, then maybe it is a Debian > problem? I installed libreoffice-3.3.1 on a different computer at work, and there it works. The differences between home and work are: - work: amd64, Debian Testing (with LibreOffice from unstable) - home: i386, Debian unstable Can't think of any other major differences. Maybe I try to remove and reinstall LibreOffice at home.
> I installed libreoffice-3.3.1 on a different computer at work, and there it > works. The differences between home and work are: > > - work: amd64, Debian Testing (with LibreOffice from unstable) > - home: i386, Debian unstable > > Can't think of any other major differences. Maybe I try to remove and reinstall > LibreOffice at home. I can confirm that it does NOT work with my LibreOffice-3.3.1 on Debian unstable on i386. I could try to install it tomorrow on one of the i386 computers in the office, to compare...
(In reply to comment #10) > > I installed libreoffice-3.3.1 on a different computer at work, and there it > > works. The differences between home and work are: > > > > - work: amd64, Debian Testing (with LibreOffice from unstable) > > - home: i386, Debian unstable > > > > Can't think of any other major differences. Maybe I try to remove and reinstall > > LibreOffice at home. > > I can confirm that it does NOT work with my LibreOffice-3.3.1 on Debian > unstable on i386. I could try to install it tomorrow on one of the i386 > computers in the office, to compare... I did a fresh install of LibreOffice-3.3.1 on a i386 machine, running Debian Testing, with LibreOffice from unstable. I removed/purged all openoffice.org packages prior to installing LibreOffice. On this machine too, the tick boxes are not remembered. So it might only be related to i386, and not to amd64 machines. However, rc2 did work on i386, as I initially worked from home, and used this feature prior to upgrading to 3.3.1.
Seems to not be a problem on amd64, but is on x86 platform.
(In reply to comment #11) > (In reply to comment #10) [...] > I did a fresh install of LibreOffice-3.3.1 on a i386 machine, running Debian > Testing, with LibreOffice from unstable. I removed/purged all openoffice.org > packages prior to installing LibreOffice. On this machine too, the tick boxes > are not remembered. So it might only be related to i386 I think this most likely this is indeed a i386 issue, I will try with i386 ( taking the bug again )
(In reply to comment #13) > I think this most likely this is indeed a i386 issue, I will try with i386 ( > taking the bug again ) I installed the 32bit version from http://download.documentfoundation.org/libreoffice/stable/3.3.1/rpm/x86/LibO_3.3.1_Linux_x86_install-rpm_en-US.tar.gz and again tried with the test document, it works as expected both with reading ( import ) and writing ( export ). Can you please check with the generic installation from the above link.
This is the rpm version. I'm on a debian based system, so would need to install the debs. It's possible that it's only a problem with the debian produced debs ..., but even there it worked with 3.3.1-rc2.
(In reply to comment #15) > It's possible that it's only a problem with the debian produced debs ..., but > even there it worked with 3.3.1-rc2. yes I know but I just want to be as certain as I can be that this is indeed a Debian specific problem ( which would be unusual ) so you could try http://download.documentfoundation.org/libreoffice/stable/3.3.1/deb/x86/LibO_3.3.1_Linux_x86_install-deb_en-US.tar.gz Rene, any insight
(In reply to comment #16) > (In reply to comment #15) > > It's possible that it's only a problem with the debian produced debs ..., but > > even there it worked with 3.3.1-rc2. > yes I know but I just want to be as certain as I can be that this is indeed a > Debian specific problem ( which would be unusual ) so you could try > http://download.documentfoundation.org/libreoffice/stable/3.3.1/deb/x86/LibO_3.3.1_Linux_x86_install-deb_en-US.tar.gz > > Rene, any insight OK - this version works. So I wonder if it is a problem with the Debian specific packages.
-> Rene to investigate further
nice try.
libreoffice (1:3.3.1-1) unstable; urgency=low * LibreOffice 3.3.1 final (identical to rc2) * debian/patches/arm-optimization: add explicit support for optimization for armv4t/6/7, based on i117017 * debian/patches/javaldx-LibreOffice.diff: s/openoffice.org/libreoffice/ for javaldx (closes: #614103) * debian/patches/alpha-no-relax.diff: use -Wl,--no-relax on alpha (https://bugs.freedesktop.org/show_bug.cgi?id=32224) * debian/patches/disable-impress-media-embedding.diff: temp fix from upstream; disable impress media embedding patches so that avmedia gets file urls passed correct again (closes: #612940) * debian/rules: - --with-arm-target=7 on armhf, explicit --with-arm-target=4 (armv4t) for armel * debian/libreoffice-common.links: s/openofficeorg3/libreoffice/ (closes: #614100) -- Rene Engelhard <rene@debian.org> Wed, 23 Feb 2011 09:07:55 +0100 I don't think any of those changes could have affected this. Maybe some external lib? To rule that our, does a downgrade of *just* LibO to 3.3.1~rc2-1 fix it? Anyway, to elaborate on my previous comment. Even if it was caused by some patch in libreoffice-build (which didn't change as rc2 == final fwiw) it still is not a debian-only bug but a libreoffice-build bug and maybe a $distro bug.
> -- Rene Engelhard <rene@debian.org> Wed, 23 Feb 2011 09:07:55 +0100 > > I don't think any of those changes could have affected this. Maybe some > external lib? To rule that our, does a downgrade of *just* LibO to 3.3.1~rc2-1 > fix it? Where can I get this package now? The debian mirrors only have 3.3.1, as far as I can see.
snapshot.debian.org?
(In reply to comment #22) > snapshot.debian.org? Yes - but which package do you want me to downgrade? libreoffice-core?
Downgrade in a way the dependencies are fullfilled? I mean, you can't downgrade -core without downgrading writer etc. anyway...
(In reply to comment #24) > Downgrade in a way the dependencies are fullfilled? I mean, you can't downgrade > -core without downgrading writer etc. anyway... I downgraded to 3.3.1-rc2, but on the machine I did it on it still doesn't work now... Strange. But it's a different machine from the one it originally worked on, which I have at home. I'm sure it worked, because I was using this very functionality on an i386 machine at home, and after upgrading to 3.3.1 it stopped working. Everything works fine on all amd64 machines (debian testing with unstable repository for libreoffice).
a little late (due to illness) back to look again at this it seems this is a very strange mix of problems e.g. 32 bit & 64 bit with some distro specifics added in to confuse things more. Now that I have managed to resurrect an old 32bit machine set up a build env to be able to build libreoffice I see the distro build on 32 bits does indeed fail. I haven't got a comparable raw ( non-distro ) build set up yet ( currently building ) to completely verify against. But... I've identified the code in question that is failing ( it's a dynamic_cast that returns null in the distro 32 bit case ), sw/source/filter/ww8/ww8par3.cxx: 230: ICheckboxFieldmark* pCheckboxFm = dynamic_cast<ICheckboxFieldmark*>(pFieldmark); interestingly ( as I always thought ) this code is identical in distro/non-distro builds. So... currently I will try to isolate what 'fun' thing is seemingly screwing up rtti on 32 bit ( distro only ) builds
Petr, the dynamic_cast in the lines mentioned in comment #26 seems to fail only with 32bit distro builds ( note: 64bit distro *and* 64bit non-distro builds seem to work fine ). Interestingly the dynamic_cast *doesn't* fail with the non-distro 32bit build. So.. there are no different compiler/linker flags ( afaics ) between the 64 & 32 bit distro build versions, there is no difference in the affected code between distro/non-distro builds. The only changes that I can see with compiler/linking between the distro and non-distro builds are those linker flag changes for 'as-needed' and 'hash-style'. This seems to point to a problem with these flags with 32bit builds alone :-/ since other dynamic_casts seem to work it would seem that rtti isn't broken but that there is possibly a compiler specific bug that is raising its head in some very specific circumstances. What do you think ? Tor, as an extra check and just to rule out any strange unforeseen interaction with some other distro patches could you check the test document with a novell windows build
needless to say there is a trivial fix here, just substitute reinterpret_cast for dynamic_cast at the problem line :-/ ( and probably any other site where attempts to dynamic_cast to ICheckboxFieldmark ) ( and yes dynamic_casting is probably not the best thing to be doing anyway.... )
Noel, could you please try to play a bit with the complier flags? For example, does it help you to compile the problematic code with -O0? Anyway, it tastes like a compiler bug, so it would be fine to use the workaround. Of course, it would be nice to report the bug to the gcc developers. Well, I am not sure how to effectively reduce a test case :-(
strange, seems this isn't related to the compile or link flags ( afaics ). I built the rawbuild sw module ( in the distro build tree ) only 1 or 2 minor code tweaks were required to do that. Running the sw libraries in the distro build results in the expected failure, running the same libraries in the rawbuild build and the we see the dynamic_cast succeeding as before. Very very weird.
Created attachment 44788 [details] workaround fix use reinterpret_cast instead of dynamic cast
->petr Do you think it is ok to commit this patch to the libreoffice-3.3 'build' repo ( e.g. into patches/dev300 & patches/dev300/apply )
ok, finally ( it was a bitch to get to the bottom of ) as a workaround you can export OOO_DISABLE_INTERNAL=something the speed-local*.diff set of patches are the problem here, ( in particular speed-local-link.diff ) it has the affect of loading libswli.so with RTLD_LOCAL ( and this affects runtime symbol resolution ) Petr, Michael said dropping that section was ok, I guess that's the best solution for now. Ok for you ?
(In reply to comment #33) > the speed-local*.diff set of patches are the problem here > > Petr, Michael said dropping that section was ok, I guess that's the best > solution for now. Ok for you ? Yes, go for it.
I've commented out those patches, marking as fixed
*** Bug 38376 has been marked as a duplicate of this bug. ***