Red Hat Bugzilla – Bug 481012
Opening *.doc with tables and saving in the same format gives no tables.
Last modified: 2009-04-16 03:49:20 EDT
Description of problem: I edited a *.doc (Office XP, I believe; not Office 2007) file with tables just fine, and saved in the same format. When opening the result (in Word or oowriter) the tables are gone. Version-Release number of selected component (if applicable): openoffice.org-writer-3.0.1-15.3.fc11.x86_64 (also with openoffice.org-writer-3.0.1-15.1.fc11.x86_64) How reproducible: Always Steps to Reproduce: 1. Get *.doc with tables 2. Edit, save with the same format 3. Reopen Actual results: Tables are gone. Expected results: Guess... Additional info:
I'll get a chance to try this tomorrow to see if it happens to all documents with tables in them, but if you have an example that definitely has this problem then please do attach it. It would seem a massive oversight to have a regression of this order from 3.0.0
Created attachment 329698 [details] this little example seems to work fine
This must be http://www.openoffice.org/issues/show_bug.cgi?id=98553
*** Bug 489074 has been marked as a duplicate of this bug. ***
*should* be ok in m4, i.e. openoffice.org-3.1.0-4.1.fc11 Will check on Monday, unless someone else can verify this in between
Bug 489074 has been marked as a duplicate of this bug. The ott file in Bug 489074 is still not correctly saved as a .doc. When opened in OO the .doc is more than the original one page length. In MS Word 2007 the table formating is not correct. These observations are recorded in bug 489074. Namaste, Kevin Tough
Got some whacked out values for spacing or something like that.
@@ -2509,7 +2509,15 @@ //ability to set the margin. SvxLRSpaceItem aL( RES_LR_SPACE ); // set right to original DxaLeft (i28656) +#if 0 + // Weird type illness aL.SetLeft( !bIsBiDi ? GetMinLeft() : pIo->maSectionManager.GetTextAreaWidth() - nPreferredWidth - nOrgDxaLeft); +#else + if (!bIsBiDi) + aL.SetLeft( GetMinLeft() ); + else + aL.SetLeft( pIo->maSectionManager.GetTextAreaWidth() - nPreferredWidth - nOrgDxaLeft ); +#endif aItemSet.Put(aL); } } sigh, replacing the ? : with an explicit if else and we get the right values. Something weird has taken place with the ? :, perhaps influenced by the mixed types on either side. SetLeft takes a long GetMinLeft returns a short GetTextAreaWidth returns a unsigned int nPreferredWidth is a short and nOrgDxaLeft is a short caolanm->jakub: known, or worth digging a test-case out of ?
Opening a .doc file containing tables no longer displays the tables. Openoffice OOO310m4 (Build: 9388), ver 3.1.0-4.1.fc11 This was working until I did the latest upgrade.
Re #8: " 6.5.15 Conditional operator … If both the second and third operands have arithmetic type, the result type that would be determined by the usual arithmetic conversions, were they applied to those two operands, is the type of the result. " so short->unsigned int->long and not short->long, oops
From this snippet I have no idea what problems do you see. Is that a compile time issue, or at runtime you see the function called with different value than it should, or different overload is called? Either a small testcase, or at least preprocessed source together with the list of g++ options used, architecture and description what to look for (e.g. what values have the different variables and what value it is then called with/what is expected) would be appreciated.
But yes, given the types the type of the ?: is unsigned int, so it is supposed to be evaluated as: SetLeft((long)(!bIsBiDi ? ((unsigned int) GetMinLeft()) : pIo->maSectionManager.GetTextAreaWidth() - (unsigned int) nPreferredWidth - (unsigned int) nOrgDxaLeft));
Created attachment 339807 [details] reference test-case Nah, there's no compiler problem here after all afaics, just weird that it went unnoticed until now that .doc import of that type of tables was whacked on x86_64 I'd love a warning for significantly mismatched ? : operands