incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ZuoJun Chen <zjchen...@gmail.com>
Subject Re: Question about Layout In Table Cell property in WW8filter
Date Fri, 08 Jun 2012 10:07:18 GMT
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 0x80000000 isn't ?  And I want to figure out the different meaning
 between 0x80008000 and 0x80000000

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 <orwittmann@googlemail.com>

> Hi,
>
>
> On 07.06.2012 15:47, ZuoJun Chen wrote:
>
>> 2012/6/7 Oliver-Rainer Wittmann<orwittmann@**googlemail.com<orwittmann@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 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<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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message