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):
(also with openoffice.org-writer-3.0.1-15.1.fc11.x86_64)
Steps to Reproduce:
1. Get *.doc with tables
2. Edit, save with the same format
Tables are gone.
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.
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)
+ // Weird type illness
aL.SetLeft( !bIsBiDi ? GetMinLeft() : pIo->maSectionManager.GetTextAreaWidth() - nPreferredWidth - nOrgDxaLeft);
+ if (!bIsBiDi)
+ aL.SetLeft( GetMinLeft() );
+ aL.SetLeft( pIo->maSectionManager.GetTextAreaWidth() - nPreferredWidth - nOrgDxaLeft );
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.
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]
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