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.
