Hi,
On 02.07.2012 12:23, Fan Zheng wrote:
2012/7/2 Oliver-Rainer Wittmann <[email protected]>
On 26.06.2012 03:57, Fan Zheng wrote:
Seeing my reply in following blue lines please:
2012/6/25 ZuoJun Chen <[email protected]>
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 <[email protected]>
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.
