From ooo-dev-return-22200-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Mon Jul 2 10:23:53 2012 Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 70F40C3F7 for ; Mon, 2 Jul 2012 10:23:53 +0000 (UTC) Received: (qmail 85339 invoked by uid 500); 2 Jul 2012 10:23:53 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 85255 invoked by uid 500); 2 Jul 2012 10:23:52 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 85232 invoked by uid 99); 2 Jul 2012 10:23:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 10:23:51 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of zheng.easyfan@gmail.com designates 209.85.161.175 as permitted sender) Received: from [209.85.161.175] (HELO mail-gg0-f175.google.com) (209.85.161.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 10:23:46 +0000 Received: by ggnp4 with SMTP id p4so3716437ggn.6 for ; Mon, 02 Jul 2012 03:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yyPXVJc5REtIfkW4YyvxGDDfZirE8YUmXIWeEAxV+2E=; b=hpLUq6KqMLmZ7s+b2ZyX1eZggW1O6NlY8ZLzmZ9YQ+3uoQ3tLOAzOeM8eD5F99dgic SB6vXtIWakVBOmCQ9WZJmPXlocHkQRtIlc74qk0KWkJcysWGg4uxcr4Lj9UZOytoUopX 8hIVGH9/LPYJdGKzPhxtBSd98V5xd6+HS3RViia1eOf/YrrVkdEkq2ZEv/c9VYm6H8Oi adLAmCR+x75WM9Xv+vP8aeCPCikaeRMsncI5QTqnqr/2FKPVVqA3wDQeEq/FjDeUNn3S ANcFJInBx/pciaSeqvpcxvzmjQGZy5Sxb7y1BGcQ0vY8GKnFywq6TYoLDEus8We54iSE HQHg== MIME-Version: 1.0 Received: by 10.42.154.199 with SMTP id r7mr5688452icw.55.1341224605684; Mon, 02 Jul 2012 03:23:25 -0700 (PDT) Received: by 10.64.43.174 with HTTP; Mon, 2 Jul 2012 03:23:25 -0700 (PDT) In-Reply-To: <4FF17405.2080508@googlemail.com> References: <4FE19A8E.2080705@googlemail.com> <4FE2F44A.9090608@googlemail.com> <4FE83663.5050601@googlemail.com> <4FF17405.2080508@googlemail.com> Date: Mon, 2 Jul 2012 18:23:25 +0800 Message-ID: Subject: Re: Question about text clipping mechanism in word processor From: Fan Zheng To: ooo-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=90e6ba6e89ea2f949a04c3d63080 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba6e89ea2f949a04c3d63080 Content-Type: text/plain; charset=ISO-8859-1 2012/7/2 Oliver-Rainer Wittmann > Hi, > > > On 26.06.2012 03:57, Fan Zheng wrote: > >> Seeing my reply in following blue lines please: >> >> 2012/6/25 ZuoJun Chen >> >> 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 >>> >>> 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 >>> >>> 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 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 ), but not part of the "frame printing area" >>>> (member ). >>>> >>>> >>> >> 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? > > Best regards, Oliver. > > --90e6ba6e89ea2f949a04c3d63080--