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 <orwittm...@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>).
>
> What do other think about it?
>
> Best regards, Oliver.
>
