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? > What do other think about it? > > > > Best regards, Oliver. > > >
