2012/7/2 Oliver-Rainer Wittmann <orwittmann@googlemail.com>

> Hi,
>
>
> On 26.06.2012 03:57, Fan Zheng wrote:
>
>> Seeing my reply in following blue lines please:
>>
>> 2012/6/25 ZuoJun Chen <zjchencdl@gmail.com>
>>
>>  Hi,
>>>     The idea sounds good to me. The task needs to accomplish piece by
>>> piece
>>> from my point of view.
>>>
>>> I'm look into text repaint process in word processor and trying to fix
>>> the
>>> character painting
>>>
>>> error in issue.119476 when inserting and deleting the text in first line
>>> of
>>> paragraph.
>>>
>>> Seems adding "additional spacing before paragraph" case to enlarge the
>>> repaint rectangle of paragraph line in
>>>
>>> <SwTxtFrm::FormatLine(..)> may be able to partially fix the problem.
>>>
>>> and the problem disturbs me is also how to store additional information
>>> :(
>>>
>>> 2012/6/25 Oliver-Rainer Wittmann <orwittmann@googlemail.com>
>>>
>>>  Hi,
>>>>
>>>>
>>>> On 22.06.2012 18:18, Fan Zheng wrote:
>>>>
>>>>  Hi, Oliver:
>>>>>
>>>>> In some degree, I changed my mind following your answer that, we should
>>>>> not
>>>>> change the definition of SvxLineSpacingItem.
>>>>>
>>>>> So based on the discussion we already have, we can do some summary. Now
>>>>>
>>>> we
>>>
>>>> know, Under the following situations:
>>>>> a. Value of above-paragraph-spacing greater than 0;
>>>>> b. The type of line-spacing is "Exactly";
>>>>> c. The value of line-spacing is less than the font height;
>>>>> MS Word will consider the above-paragraph-spacing as the additional
>>>>> line-spacing for the first line. Also, MS Word doing funny stuff
>>>>>
>>>> commonly
>>>
>>>> because the in-consistent process mechanism, such as the background
>>>>>
>>>> height
>>>
>>>> and flying object positing stuff.
>>>>>
>>>>> In a further step, we considered that AOO has fidelity issues on
>>>>> representing such kind of MS Word document with the properties settings
>>>>>
>>>> we
>>>
>>>> talked about, and we want to fix it.
>>>>>
>>>>> So far so good. But what should be the range of the fix? In my opinion,
>>>>>
>>>> we
>>>
>>>> should consider  following candidates:
>>>>> a. Preventing the text presentation clipping in first line in above
>>>>> condition, as ZJ already done perfectly;
>>>>> b. Consistency behavior of paint refresh and cursor selection; The hard
>>>>> point of this one is that, when refreshing a line portion painting
>>>>> (including the selection range stuff), the paint range is clipped
>>>>>
>>>> already
>>>
>>>> to fit the size of line portion. We may need some kind of breaking
>>>>>
>>>> method
>>>
>>>> on working with "big" line spacing.  Such method may need to change the
>>>>> VisArea of a SwTxtFrm;
>>>>> c. Following the in-consistent process mechanism that MS Word has; I
>>>>> really
>>>>> do not want it, but without it, the fidelity issues still there.
>>>>> d. Making the documents loaded from ODF files also work like this;
>>>>>
>>>>> So for me, ZuoJun's work maybe acceptable, but it is only a very
>>>>>
>>>> beginning
>>>
>>>> of big works.
>>>>>
>>>>>
>>>>>  I agree to ZhengFan's analysis.
>>>>
>>>> Now, we need to discuss how we address these issues.
>>>>
>>>> My view one this is the following (propsal for discussion):
>>>> - Let us separate the stuff regarding the character painting and the
>>>> object positioning stuff in two issue. 119476 for the character
>>>> painting,
>>>> new issue for the object positioning stuff.
>>>> - Character painting stuff:
>>>> -- I am in favor of a solution which does not change our intrinsic text
>>>> formatting and line portion creation algorithm. Thus, to solve the
>>>>
>>> repaint
>>>
>>>> and selection problem we can store additional information - the
>>>>
>>> additional
>>>
>>>> space taken by the character painting - at the <SwTxtFrm> instance in
>>>>
>>> order
>>>
>>>> to access it during painting and selection actions. The additional space
>>>> taken for the character painting is already part of the "frame area"
>>>> (member <SwTxtFrm::aFrm>), but not part of the "frame printing area"
>>>> (member <SwTxtFrm::aPrt>).
>>>>
>>>>
>>>
>> 1 Concern:
>>
>> Could such additional information to be available in ODF Standard?
>> If not, whether it means that, the conversion from MS-Word Doc to ODT lead
>> different representation result?
>>
>>
>>
> I do not think that this is an ODF issue.
> The ODF specification does not say anything about the need to clip the
> text, if it does not fit into the given/calculated line height.
>

Hi, Oliver:

So what will happen, if we give the support on such clipping stuff in MS
Word for the issue we discussed, and then save the document into an ODT
file?


>
> Best regards, Oliver.
>
>