Bug 481012 - Opening *.doc with tables and saving in the same format gives no tables.
Opening *.doc with tables and saving in the same format gives no tables.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
: OOCompIssue (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-21 13:13 EST by Horst H. von Brand
Modified: 2009-04-16 03:49 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-30 04:50:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
this little example seems to work fine (8.00 KB, application/msword)
2009-01-22 03:58 EST, Caolan McNamara
no flags Details
reference test-case (416 bytes, text/plain)
2009-04-16 03:49 EDT, Caolan McNamara
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 98553 None None None Never

  None (edit)
Description Horst H. von Brand 2009-01-21 13:13:58 EST
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:
Comment 1 Caolan McNamara 2009-01-21 18:01:47 EST
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
Comment 2 Caolan McNamara 2009-01-22 03:58:22 EST
Created attachment 329698 [details]
this little example seems to work fine
Comment 3 Caolan McNamara 2009-01-28 08:55:01 EST
This must be http://www.openoffice.org/issues/show_bug.cgi?id=98553
Comment 4 Caolan McNamara 2009-03-07 09:08:46 EST
*** Bug 489074 has been marked as a duplicate of this bug. ***
Comment 5 Caolan McNamara 2009-03-07 09:09:40 EST
*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
Comment 6 Kevin Tough 2009-03-07 13:57:07 EST
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
Comment 7 Caolan McNamara 2009-03-09 12:03:10 EDT
Got some whacked out values for spacing or something like that.
Comment 8 Caolan McNamara 2009-03-10 10:01:58 EDT
@@ -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 ?
Comment 9 Stephen 2009-03-13 11:58:39 EDT
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.
Comment 10 Caolan McNamara 2009-04-15 11:18:16 EDT
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
Comment 11 Jakub Jelinek 2009-04-15 12:25:21 EDT
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.
Comment 12 Jakub Jelinek 2009-04-15 12:32:07 EDT
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));
Comment 13 Caolan McNamara 2009-04-16 03:49:20 EDT
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

Note You need to log in before you can comment on or make changes to this bug.