openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject Re: Question about text clipping mechanism in word processor
Date Mon, 02 Jul 2012 10:12:21 GMT

On 26.06.2012 03:57, Fan Zheng wrote:
> Seeing my reply in following blue lines please:
> 2012/6/25 ZuoJun Chen <>
>> 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 <>
>>> 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.

Best regards, Oliver.

View raw message