Re: Question about Layout In Table Cell property in WW8filter

2012-06-08 Thread Oliver-Rainer Wittmann

Hi,

On 07.06.2012 15:47, ZuoJun Chen wrote:

2012/6/7 Oliver-Rainer Wittmannorwittm...@googlemail.com


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 0x8000 in ww8graf.cxx Line 2483.  From the
discussion in issue
84783https://issues.apache.**org/ooo/show_bug.cgi?id=84783https://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 
methodSwWW8ImplReader::**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 methodSwWW8ImplReader::**
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  0x8000 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 == 0x || // no explicit attribute value given
 nLayoutInTableCell == 0x80008000 ||
^^
 ( nLayoutInTableCell  0x0200 
   !(nLayoutInTableCell  0x8000 ) ) )
{
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 == 0x8000 )
   !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.


Re: Question about Layout In Table Cell property in WW8filter

2012-06-08 Thread ZuoJun Chen
Hi, Oliver

   Thanks again for your patch to issue 119624. also I benefit a lot from
your response  :)

   Does the change from nLayoutInTableCell   0x80008000 to nLayoutInTableCell
== 0x80008000 mean that

the value 0x80008000 is the flag indicates Layout in Table cell property
has been checked,

while 0x8000 isn't ?  And I want to figure out the different meaning
 between 0x80008000 and 0x8000

since I cannot see further information except parameter 0x03BF indicates
the AutoFormat options

in MS Word binary format specification.



2012/6/8 Oliver-Rainer Wittmann orwittm...@googlemail.com

 Hi,


 On 07.06.2012 15:47, ZuoJun Chen wrote:

 2012/6/7 Oliver-Rainer 
 Wittmannorwittmann@**googlemail.comorwittm...@googlemail.com
 

  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 0x8000 in ww8graf.cxx Line 2483.  From the
 discussion in issue
 84783https://issues.apache.org/ooo/show_bug.cgi?id=84783**
 https://issues.apache.org/ooo/**show_bug.cgi?id=84783https://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 methodSwWW8ImplReader::
 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 methodSwWW8ImplReader::**
 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  0x8000 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 == 0x || // no explicit attribute value
 given
 nLayoutInTableCell == 0x80008000 ||
^^
 ( nLayoutInTableCell  0x0200 
   !(nLayoutInTableCell  0x8000 ) ) )
 {
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 == 0x8000 )
   !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.



Re: Question about Layout In Table Cell property in WW8filter

2012-06-08 Thread Oliver-Rainer Wittmann

Hi,

On 08.06.2012 12:07, ZuoJun Chen wrote:

Hi, Oliver

Thanks again for your patch to issue 119624. also I benefit a lot from
your response  :)

Does the change from nLayoutInTableCell   0x80008000 to nLayoutInTableCell
== 0x80008000 mean that

the value 0x80008000 is the flag indicates Layout in Table cell property
has been checked,



Yes, at least this reveals from my investigations.


while 0x8000 isn't ?  And I want to figure out the different meaning
  between 0x80008000 and 0x8000

since I cannot see further information except parameter 0x03BF indicates
the AutoFormat options

in MS Word binary format specification.



As I had never a deep look into this specification I do not know more.

My investigations results in the implementation of method 
SwWW8ImplReader::IsObjectLayoutInTableCell(..)


- value == 0x means LayoutInTableCell is set
- value == 0x80008000 means LayoutInTableCell is set
- ( value  0x0200 AND
!(value  0x8000) ) means LayoutInTableCell is set


Best regards, Oliver.




2012/6/8 Oliver-Rainer Wittmannorwittm...@googlemail.com


Hi,


On 07.06.2012 15:47, ZuoJun Chen wrote:


2012/6/7 Oliver-Rainer 
Wittmannorwittmann@**googlemail.comorwittm...@googlemail.com




  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 0x8000 in ww8graf.cxx Line 2483.  From the
discussion in issue
84783https://issues.apache.org/ooo/show_bug.cgi?id=84783**
https://issues.apache.org/ooo/**show_bug.cgi?id=84783https://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 methodSwWW8ImplReader::

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 methodSwWW8ImplReader::**
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  0x8000 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 
methodSwWW8ImplReader::**IsObjectLayoutInTableCell(..)
is wrong I think.
It must must be:
if ( nLayoutInTableCell == 0x || // no explicit attribute value
given
 nLayoutInTableCell == 0x80008000 ||
^^
 ( nLayoutInTableCell  0x0200
   !(nLayoutInTableCell  0x8000 ) ) )
{
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 methodSwWW8ImplReader::**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 == 0x8000 )
   !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.





Re: Question about Layout In Table Cell property in WW8filter

2012-06-07 Thread Oliver-Rainer Wittmann

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 0x8000 in ww8graf.cxx Line 2483.  From the
discussion in issue
84783https://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.


Best regards, Oliver.