Hi,

On 07.06.2012 15:47, ZuoJun Chen wrote:
2012/6/7 Oliver-Rainer Wittmann<[email protected]>

Hi,


On 07.06.2012 13:34, ZuoJun Chen wrote:

Hi, All,

     There is an attribute for anchored objects named "Layout In Table Cell
property"  in MS Word.

WW8 filter will check this attribute when import shape in table. I am
puzzled that there are two hex magic number

0x80008000 and 0x80000000 in ww8graf.cxx Line 2483.  From the
discussion in issue
84783<https://issues.apache.**org/ooo/show_bug.cgi?id=84783<https://issues.apache.org/ooo/show_bug.cgi?id=84783>
**, I can see that

these

number may associate with MS Word Binary File Format Specification, not
sure
whether both number indicate that

"Layout in table cell" is set. I checked the documentation but didn't
found
more details. So I post this mail

  to see if I could get any sort of advice.


I am the author of the corresponding 
method<SwWW8ImplReader::**IsObjectLayoutInTableCell(..)>
containing the above "magic number" interpretation. As far as I remember
the initial implementation was done this issue 84783 and an adoption has
been made with issue 98037.

As far as I remembering it correct the implemented interpretation of this
"magic number" was done by the evaluation of different Microsoft Word
documents created with different Microsoft Office versions.

I am currently looking at issue 119624. The root cause of this issue seems
to be related to my implemetation in method<SwWW8ImplReader::**
IsObjectLayoutInTableCell(..)>**.
I have to do some further investigations - please stay tuned for the
results.


Hi, Oliver,

    Thank you for you reply. I think the number considering a flag to
indicate

whether the "Layout In Table Cell“ property has been checked.

However, when use nLayoutInTableCell&  0x80008000 to determine the

property. Both 0x80008000 or  0x80000000 can set the
bIsObjectLayoutInTableCell = true.

Do the two hex number represent same meaning?


No, I do not think so.

My implementation of the conditions in method <SwWW8ImplReader::IsObjectLayoutInTableCell(..)> is wrong I think.
It must must be:
if ( nLayoutInTableCell == 0xFFFFFFFF || // no explicit attribute value given
     nLayoutInTableCell == 0x80008000 ||
                        ^^
     ( nLayoutInTableCell & 0x02000000 &&
       !(nLayoutInTableCell & 0x80000000 ) ) )
{
    bIsObjectLayoutInTableCell = true;
}
else
{
    bIsObjectLayoutInTableCell = false;
}

Testing "nLayoutInTableCell & 0x80008000" in the second condition does not make sense regarding the third condition.

The above change in one part of the fix for issue 119624 in order to get the horizontal position correctly mapped. Because this a corrected method <SwWW8ImplReader::IsObjectLayoutInTableCell(..)> the following code found in method <SwWW8ImplReader::ProcessEscherAlign(..)> will apply:
  // --> OD 2005-01-20 #118546# - if the object is anchored inside
  // a table cell, is horizontal aligned at frame|character and
  // has wrap through, but its attribute 'layout in table cell' isn't set,
  // convert its horizontal alignment to page text area.
  // --> OD 2008-04-10 #i84783# - use new method <IsObjectLayoutInTableCell()>
  if ( nInTable &&
       ( eHoriRel == text::RelOrientation::FRAME ||
         eHoriRel == text::RelOrientation::CHAR ) &&
       pFSPA->nwr == 3 &&
//     pRecord->nLayoutInTableCell == 0x80000000 )
       !IsObjectLayoutInTableCell( pRecord->nLayoutInTableCell ) )
  {
      eHoriRel = text::RelOrientation::PAGE_PRINT_AREA;
  }
  // <--

I have attached a corresponding patch for the above code changes to issue 
119624.

But, there are more defects with the import and layout of Microsoft Word document given at issue 119624 - please my comments in this issue.

Best regards, Oliver.

Reply via email to