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 11:26:37 GMT
Hi,

On 02.07.2012 12:23, Fan Zheng wrote:
> 2012/7/2 Oliver-Rainer Wittmann <orwittmann@googlemail.com>
>> 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?
>

 From my point of view the discussed changes are rendering/painting related - 
they are not related to the document model and attributes.
Thus, from my point of view neither the export to ODF nor the export to 
Microsoft Word binary format needs to be adjusted.

Best regards, Oliver.


Mime
View raw message