incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject Re: Question about text clipping mechanism in word processor
Date Mon, 02 Jul 2012 10:12:21 GMT
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.

Best regards, Oliver.


Mime
View raw message