Bug 481012 - Opening *.doc with tables and saving in the same format gives no tables.
Summary: Opening *.doc with tables and saving in the same format gives no tables.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: x86_64
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: OOCompIssue (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-21 18:13 UTC by Horst H. von Brand
Modified: 2009-04-16 07:49 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-03-30 08:50:46 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
OpenOffice.org 98553 0 None None None Never

Description Horst H. von Brand 2009-01-21 18:13:58 UTC
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 23:01:47 UTC
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 08:58:22 UTC
Created attachment 329698 [details]
this little example seems to work fine

Comment 3 Caolan McNamara 2009-01-28 13:55:01 UTC
This must be http://www.openoffice.org/issues/show_bug.cgi?id=98553

Comment 4 Caolan McNamara 2009-03-07 14:08:46 UTC
*** Bug 489074 has been marked as a duplicate of this bug. ***

Comment 5 Caolan McNamara 2009-03-07 14:09:40 UTC
*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 18:57:07 UTC
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 16:03:10 UTC
Got some whacked out values for spacing or something like that.

Comment 8 Caolan McNamara 2009-03-10 14:01:58 UTC
@@ -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 15:58:39 UTC
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 15:18:16 UTC
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 16:25:21 UTC
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 16:32:07 UTC
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 07:49:20 UTC
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.