incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fan Zheng <zheng.easy...@gmail.com>
Subject Re: Question about text clipping mechanism in word processor
Date Tue, 26 Jun 2012 01:57:11 GMT
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?


> What do other think about it?
> >
> > Best regards, Oliver.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message