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, 25 Jun 2012 09:58:59 GMT
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.

Mime
View raw message