You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by ZuoJun Chen <zj...@gmail.com> on 2012/06/20 10:47:08 UTC
Question about text clipping mechanism in word processor
Hi All,
I'm trying to handle a bug on text clipped in document . See Bug
119476 <https://issues.apache.org/ooo/show_bug.cgi?id=119476> for more
details.
After investigation, I have some insights. When paragraph line spacing is
smaller than font size,
the text contained becomes too large for fit, then AOO will clipped text
as Incomplete part. The code
for text clipped mechanism can be located in method
<SwTxtFormatter::CalcRealHeight(..)> at
sw\source\core\text\itrform2.cxx line 1756.
I thought that the preferable way to fix this would be to considering the
spacing contains above paragraph
spacing property and line spacing property as the conditions to determine
whether clipping text. e.g.
Clipped text if the sum of adding above paragraph spacing and line
paragraph spacing is smaller than font size,
otherwise do not clip text since above paragraph spacing and line spacing
are enough to display the text.
Noticed that there is a property named below paragraph spacing, but I'm
not sure whether there is a need to consider this one,
Do this property impact text clipped in paragraph?
Any idea greatly appreciated.
Regards, Zuojun
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 02.07.2012 12:23, Fan Zheng wrote:
> 2012/7/2 Oliver-Rainer Wittmann <or...@googlemail.com>
>> On 26.06.2012 03:57, Fan Zheng wrote:
>>
>>> Seeing my reply in following blue lines please:
>>>
>>> 2012/6/25 ZuoJun Chen <zj...@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 <or...@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?
>>>
>>>
>>>
>> 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.
Re: Question about text clipping mechanism in word processor
Posted by Fan Zheng <zh...@gmail.com>.
2012/7/2 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 26.06.2012 03:57, Fan Zheng wrote:
>
>> Seeing my reply in following blue lines please:
>>
>> 2012/6/25 ZuoJun Chen <zj...@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 <or...@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?
>>
>>
>>
> 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.
>
>
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 26.06.2012 03:57, Fan Zheng wrote:
> Seeing my reply in following blue lines please:
>
> 2012/6/25 ZuoJun Chen <zj...@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 <or...@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?
>
>
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.
Best regards, Oliver.
Re: Question about text clipping mechanism in word processor
Posted by Fan Zheng <zh...@gmail.com>.
Seeing my reply in following blue lines please:
2012/6/25 ZuoJun Chen <zj...@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 <or...@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.
> >
>
Re: Question about text clipping mechanism in word processor
Posted by ZuoJun Chen <zj...@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 <or...@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>).
>
> What do other think about it?
>
> Best regards, Oliver.
>
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@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>).
What do other think about it?
Best regards, Oliver.
Re: Question about text clipping mechanism in word processor
Posted by Fan Zheng <zh...@gmail.com>.
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.
2012/6/21 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 21.06.2012 11:23, Fan Zheng wrote:
>
>> Hi, All:
>>
>> Let me talk about my concern.
>>
>> Regarding the value is correct, there may exist the formatting mechanism
>> difference.
>>
>> 1. MS Word consider the above-paragraph-spacing + line-spacing (may also
>> including the below-paragraph-spacing? not sure) as the available vertical
>> space for containing text;
>>
>
> My investigation of MS word 2003 and 2010 reveals the following:
> - the additional space of above-paragraph-spacing for rendering the text
> of the first text line.
> - the below-paragraph-spacing from the previous paragraph is _not_ used
> for rendering the text of the first text line.
> - for the character background and the paragraph background the
> above-paragraph-spacing is _not_ used. Thus, it looks very funny in MS Word
> 2003/2010 when the additional space is used for the characters, but not for
> the different backgrounds.
> - for object positioning the above-paragraph-spacing is used. Thus, an
> object whose vertical position is 0cm to the top of the line also looks
> funny from my point of view.
>
> My conclusion here is that MS Word is doing really inconsistent and funny
> things.
>
>
> 2. OpenOffice consider the ling-spacing only as the available vertical
>> space for containing text;
>>
>> Is that correct? If yes, then the inner value of line-spacing inside
>> SvxLineSpacingItem should actually equal to the value
>> of "above-paragraph-spacing + line-spacing" stored in DOC files;
>> And in my opinion, such modification should be in filter but not in
>> formatting;
>>
>>
> Yes, for your question.
> But I disagree regarding adjusting the value of the SvxLineSpacingItem:
> (1) We have no SvxLineSpacingItem for the first line and the rest of the
> text lines. Such a features also does not exist in ODF. From my point of
> view such a feature does not make sense.
> (2) The above-paragaph-spacing belongs to the corresponding Svx...Item
> which represent the paragraphh margins.
> (3) MS Word is doing really inconsistent and funny things here. I am
> proposing _not_ to reflect these in our document model.
>
>
> A further question is: as the total vertical space include above, line and
>> below are actually available for containing text, why MS Word trying to
>> distinguish them? On some other words, what the exact meaning of above and
>> below paragraph spacing in MS word?
>>
>>
> As I am not the expert of MS Word and its file format I can not answer
> these questions. From my point of view only MS experts can answer them.
>
>
> And following the tips from Oliver, such value should only works on the
>> first line of paragraph. So whether it means that, the
>> above-paragraph-spacing has some kind of difference definition to the UL
>> space inside OpenOffice?
>>
>>
> Here, I am not sure, if I am getting the point.
>
> Best regards, Oliver.
>
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.06.2012 11:23, Fan Zheng wrote:
> Hi, All:
>
> Let me talk about my concern.
>
> Regarding the value is correct, there may exist the formatting mechanism
> difference.
>
> 1. MS Word consider the above-paragraph-spacing + line-spacing (may also
> including the below-paragraph-spacing? not sure) as the available vertical
> space for containing text;
My investigation of MS word 2003 and 2010 reveals the following:
- the additional space of above-paragraph-spacing for rendering the text of the
first text line.
- the below-paragraph-spacing from the previous paragraph is _not_ used for
rendering the text of the first text line.
- for the character background and the paragraph background the
above-paragraph-spacing is _not_ used. Thus, it looks very funny in MS Word
2003/2010 when the additional space is used for the characters, but not for the
different backgrounds.
- for object positioning the above-paragraph-spacing is used. Thus, an object
whose vertical position is 0cm to the top of the line also looks funny from my
point of view.
My conclusion here is that MS Word is doing really inconsistent and funny things.
> 2. OpenOffice consider the ling-spacing only as the available vertical
> space for containing text;
>
> Is that correct? If yes, then the inner value of line-spacing inside
> SvxLineSpacingItem should actually equal to the value
> of "above-paragraph-spacing + line-spacing" stored in DOC files;
> And in my opinion, such modification should be in filter but not in
> formatting;
>
Yes, for your question.
But I disagree regarding adjusting the value of the SvxLineSpacingItem:
(1) We have no SvxLineSpacingItem for the first line and the rest of the text
lines. Such a features also does not exist in ODF. From my point of view such a
feature does not make sense.
(2) The above-paragaph-spacing belongs to the corresponding Svx...Item which
represent the paragraphh margins.
(3) MS Word is doing really inconsistent and funny things here. I am proposing
_not_ to reflect these in our document model.
> A further question is: as the total vertical space include above, line and
> below are actually available for containing text, why MS Word trying to
> distinguish them? On some other words, what the exact meaning of above and
> below paragraph spacing in MS word?
>
As I am not the expert of MS Word and its file format I can not answer these
questions. From my point of view only MS experts can answer them.
> And following the tips from Oliver, such value should only works on the
> first line of paragraph. So whether it means that, the
> above-paragraph-spacing has some kind of difference definition to the UL
> space inside OpenOffice?
>
Here, I am not sure, if I am getting the point.
Best regards, Oliver.
Re: Question about text clipping mechanism in word processor
Posted by Fan Zheng <zh...@gmail.com>.
Hi, All:
Let me talk about my concern.
Regarding the value is correct, there may exist the formatting mechanism
difference.
1. MS Word consider the above-paragraph-spacing + line-spacing (may also
including the below-paragraph-spacing? not sure) as the available vertical
space for containing text;
2. OpenOffice consider the ling-spacing only as the available vertical
space for containing text;
Is that correct? If yes, then the inner value of line-spacing inside
SvxLineSpacingItem should actually equal to the value
of "above-paragraph-spacing + line-spacing" stored in DOC files;
And in my opinion, such modification should be in filter but not in
formatting;
A further question is: as the total vertical space include above, line and
below are actually available for containing text, why MS Word trying to
distinguish them? On some other words, what the exact meaning of above and
below paragraph spacing in MS word?
And following the tips from Oliver, such value should only works on the
first line of paragraph. So whether it means that, the
above-paragraph-spacing has some kind of difference definition to the UL
space inside OpenOffice?
2012/6/20 Joost Andrae <Jo...@gmx.de>
> Hi,
>
> Am 20.06.2012 13:43, schrieb ZuoJun Chen:
>
> Hi, Fan
>>
>> I have extracted parameter from first paragraph in sample file
>>
>> 1 Spacing before paragraph 18pt in doc file
>> 2 above-paragraph-spacing in SvxULSpaceItem: 360
>> 3 line-spacing of said para in doc file: 12pt
>> 4 line-spacing of said para in SvxLineSpacingItem:240
>>
>> Seems that the value mapping works, Looking forward to your further
>> response:)
>>
>
> soffice internally uses twips and msoffice uses pt
>
> https://en.wikipedia.org/wiki/**Twip <https://en.wikipedia.org/wiki/Twip>
>
> Above values are correct.
>
> Kind regards, Joost
>
>
Re: Question about text clipping mechanism in word processor
Posted by Joost Andrae <Jo...@gmx.de>.
Hi,
Am 20.06.2012 13:43, schrieb ZuoJun Chen:
> Hi, Fan
>
> I have extracted parameter from first paragraph in sample file
>
> 1 Spacing before paragraph 18pt in doc file
> 2 above-paragraph-spacing in SvxULSpaceItem: 360
> 3 line-spacing of said para in doc file: 12pt
> 4 line-spacing of said para in SvxLineSpacingItem:240
>
> Seems that the value mapping works, Looking forward to your further
> response:)
soffice internally uses twips and msoffice uses pt
https://en.wikipedia.org/wiki/Twip
Above values are correct.
Kind regards, Joost
Re: Question about text clipping mechanism in word processor
Posted by ZuoJun Chen <zj...@gmail.com>.
Hi, Fan
I have extracted parameter from first paragraph in sample file
1 Spacing before paragraph 18pt in doc file
2 above-paragraph-spacing in SvxULSpaceItem: 360
3 line-spacing of said para in doc file: 12pt
4 line-spacing of said para in SvxLineSpacingItem:240
Seems that the value mapping works, Looking forward to your further
response:)
2012/6/20 Fan Zheng <zh...@gmail.com>
> Hi ZJ:
>
> Sorry, perhaps I missed something. Would you please give me following data
> of this specified sample file?
>
> 1. The exact value of the above-paragraph-spacing of said para, recorded in
> the DOC file;
> 2. The exact value of the above-paragraph-spacing of said para, recorded in
> SvxULSpaceItem, when trying to format it;
> 3. The exact value of the line-spacing of said para, recorded in the DOC
> file;
> 4. The exact value of the line-spacing of said para, recorded in
> SvxLineSpacingItem, when trying to format it;
>
> By comparing the above values, we may confirm that, this is a value mapping
> issue or, a strategy difference issue.
>
> 2012/6/20 Oliver-Rainer Wittmann <or...@googlemail.com>
>
> > Hi,
> >
> >
> > On 20.06.2012 10:47, ZuoJun Chen wrote:
> >
> >> Hi All,
> >>
> >> I'm trying to handle a bug on text clipped in document . See Bug
> >> 119476<https://issues.apache.**org/ooo/show_bug.cgi?id=119476<
> https://issues.apache.org/ooo/show_bug.cgi?id=119476>
> >> **> for more
> >> details.
> >>
> >> After investigation, I have some insights. When paragraph line spacing
> is
> >> smaller than font size,
> >>
> >> the text contained becomes too large for fit, then AOO will clipped text
> >> as Incomplete part. The code
> >>
> >> for text clipped mechanism can be located in method
> >> <SwTxtFormatter::**CalcRealHeight(..)> at
> >>
> >> sw\source\core\text\itrform2.**cxx line 1756.
> >>
> >>
> >> I thought that the preferable way to fix this would be to considering
> the
> >> spacing contains above paragraph
> >>
> >> spacing property and line spacing property as the conditions to
> determine
> >> whether clipping text. e.g.
> >>
> >> Clipped text if the sum of adding above paragraph spacing and line
> >> paragraph spacing is smaller than font size,
> >>
> >> otherwise do not clip text since above paragraph spacing and line
> spacing
> >> are enough to display the text.
> >>
> >>
> > From my point of view this change makes sense.
> > If the text of the first line of a paragraph "founds" enough space in the
> > "above paragraph spacing", the text should not be clipped.
> >
> > I had already looked at the patch and it looks ok.
> > I will have a deeper look regarding how to determine the value of "above
> > paragraph spacing". As far as I remember in some cases depending on
> certain
> > compatibility option, the "above paragraph spacing" is not applied. E.g.,
> > if the paragraph is the first on a page and compatibility option "Add
> > paragraph and table spacing at tops of pages ..." is not checked, the
> > "above paragraph spacing" is not applied.
> > May be I find a solution to access the already calculated and applied
> > "above paragraph spacing".
> >
> >
> >
> >> Noticed that there is a property named below paragraph spacing, but I'm
> >> not sure whether there is a need to consider this one,
> >>
> >> Do this property impact text clipped in paragraph?
> >>
> >>
> > May be - I am not sure.
> > Thus, a paragraph could have a "below paragraph spacing" and the first
> > text line of the following paragraph could be to small. This would cause
> > clipping, but may be the "below paragraph spacing" from the previous
> > paragraph could be used to avoid the clipping.
> > From my point of view avoid the clipping in this case would also make
> > sense.
> > May be my above mentioned further investigation regarding the available
> > space above the first text line of a paragraph would solve this, too.
> >
> > Zuojun, do you know how MS Word will behave in this case?
> >
> >
> > Best regards, Oliver.
> >
>
Re: Question about text clipping mechanism in word processor
Posted by Fan Zheng <zh...@gmail.com>.
Hi ZJ:
Sorry, perhaps I missed something. Would you please give me following data
of this specified sample file?
1. The exact value of the above-paragraph-spacing of said para, recorded in
the DOC file;
2. The exact value of the above-paragraph-spacing of said para, recorded in
SvxULSpaceItem, when trying to format it;
3. The exact value of the line-spacing of said para, recorded in the DOC
file;
4. The exact value of the line-spacing of said para, recorded in
SvxLineSpacingItem, when trying to format it;
By comparing the above values, we may confirm that, this is a value mapping
issue or, a strategy difference issue.
2012/6/20 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 20.06.2012 10:47, ZuoJun Chen wrote:
>
>> Hi All,
>>
>> I'm trying to handle a bug on text clipped in document . See Bug
>> 119476<https://issues.apache.**org/ooo/show_bug.cgi?id=119476<https://issues.apache.org/ooo/show_bug.cgi?id=119476>
>> **> for more
>> details.
>>
>> After investigation, I have some insights. When paragraph line spacing is
>> smaller than font size,
>>
>> the text contained becomes too large for fit, then AOO will clipped text
>> as Incomplete part. The code
>>
>> for text clipped mechanism can be located in method
>> <SwTxtFormatter::**CalcRealHeight(..)> at
>>
>> sw\source\core\text\itrform2.**cxx line 1756.
>>
>>
>> I thought that the preferable way to fix this would be to considering the
>> spacing contains above paragraph
>>
>> spacing property and line spacing property as the conditions to determine
>> whether clipping text. e.g.
>>
>> Clipped text if the sum of adding above paragraph spacing and line
>> paragraph spacing is smaller than font size,
>>
>> otherwise do not clip text since above paragraph spacing and line spacing
>> are enough to display the text.
>>
>>
> From my point of view this change makes sense.
> If the text of the first line of a paragraph "founds" enough space in the
> "above paragraph spacing", the text should not be clipped.
>
> I had already looked at the patch and it looks ok.
> I will have a deeper look regarding how to determine the value of "above
> paragraph spacing". As far as I remember in some cases depending on certain
> compatibility option, the "above paragraph spacing" is not applied. E.g.,
> if the paragraph is the first on a page and compatibility option "Add
> paragraph and table spacing at tops of pages ..." is not checked, the
> "above paragraph spacing" is not applied.
> May be I find a solution to access the already calculated and applied
> "above paragraph spacing".
>
>
>
>> Noticed that there is a property named below paragraph spacing, but I'm
>> not sure whether there is a need to consider this one,
>>
>> Do this property impact text clipped in paragraph?
>>
>>
> May be - I am not sure.
> Thus, a paragraph could have a "below paragraph spacing" and the first
> text line of the following paragraph could be to small. This would cause
> clipping, but may be the "below paragraph spacing" from the previous
> paragraph could be used to avoid the clipping.
> From my point of view avoid the clipping in this case would also make
> sense.
> May be my above mentioned further investigation regarding the available
> space above the first text line of a paragraph would solve this, too.
>
> Zuojun, do you know how MS Word will behave in this case?
>
>
> Best regards, Oliver.
>
Re: Question about text clipping mechanism in word processor
Posted by ZuoJun Chen <zj...@gmail.com>.
Hi, Oliver
Thanks for your response:). For the case a paragraph with below
paragraph spacing and line spacing of following paragraph is smaller than
font size,
MS Word will also clipped the text in the following paragraph in spite of
there is enough
below paragraph spacing from former paragraph. I posted a sample file in
attachments for this case.
I have noticed your comment in bugzilla, and will have a further think
about it.
2012/6/20 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 20.06.2012 11:40, Oliver-Rainer Wittmann wrote:
>
>> On 20.06.2012 10:47, ZuoJun Chen wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to handle a bug on text clipped in document . See Bug
>>> 119476<https://issues.apache.**org/ooo/show_bug.cgi?id=119476<https://issues.apache.org/ooo/show_bug.cgi?id=119476>
>>> **> for more
>>> details.
>>>
>>> After investigation, I have some insights. When paragraph line spacing is
>>> smaller than font size,
>>>
>>> the text contained becomes too large for fit, then AOO will clipped text
>>> as Incomplete part. The code
>>>
>>> for text clipped mechanism can be located in method
>>> <SwTxtFormatter::**CalcRealHeight(..)> at
>>>
>>> sw\source\core\text\itrform2.**cxx line 1756.
>>>
>>>
>>> I thought that the preferable way to fix this would be to considering the
>>> spacing contains above paragraph
>>>
>>> spacing property and line spacing property as the conditions to determine
>>> whether clipping text. e.g.
>>>
>>> Clipped text if the sum of adding above paragraph spacing and line
>>> paragraph spacing is smaller than font size,
>>>
>>> otherwise do not clip text since above paragraph spacing and line spacing
>>> are enough to display the text.
>>>
>>>
>> From my point of view this change makes sense.
>> If the text of the first line of a paragraph "founds" enough space in the
>> "above
>> paragraph spacing", the text should not be clipped.
>>
>> I had already looked at the patch and it looks ok.
>> I will have a deeper look regarding how to determine the value of "above
>> paragraph spacing". As far as I remember in some cases depending on
>> certain
>> compatibility option, the "above paragraph spacing" is not applied. E.g.,
>> if the
>> paragraph is the first on a page and compatibility option "Add paragraph
>> and
>> table spacing at tops of pages ..." is not checked, the "above paragraph
>> spacing" is not applied.
>> May be I find a solution to access the already calculated and applied
>> "above
>> paragraph spacing".
>>
>>
> I had a deeper review on the patch.
> Please see my comment in the issue [1].
>
> [1] https://issues.apache.org/ooo/**show_bug.cgi?id=119476#c5<https://issues.apache.org/ooo/show_bug.cgi?id=119476#c5>
>
>
> Best regards, Oliver.
>
>
>
>>> Noticed that there is a property named below paragraph spacing, but I'm
>>> not sure whether there is a need to consider this one,
>>>
>>> Do this property impact text clipped in paragraph?
>>>
>>>
>> May be - I am not sure.
>> Thus, a paragraph could have a "below paragraph spacing" and the first
>> text line
>> of the following paragraph could be to small. This would cause clipping,
>> but may
>> be the "below paragraph spacing" from the previous paragraph could be
>> used to
>> avoid the clipping.
>> From my point of view avoid the clipping in this case would also make
>> sense.
>> May be my above mentioned further investigation regarding the available
>> space
>> above the first text line of a paragraph would solve this, too.
>>
>> Zuojun, do you know how MS Word will behave in this case?
>>
>>
>> Best regards, Oliver.
>>
>
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 20.06.2012 11:40, Oliver-Rainer Wittmann wrote:
> On 20.06.2012 10:47, ZuoJun Chen wrote:
>> Hi All,
>>
>> I'm trying to handle a bug on text clipped in document . See Bug
>> 119476<https://issues.apache.org/ooo/show_bug.cgi?id=119476> for more
>> details.
>>
>> After investigation, I have some insights. When paragraph line spacing is
>> smaller than font size,
>>
>> the text contained becomes too large for fit, then AOO will clipped text
>> as Incomplete part. The code
>>
>> for text clipped mechanism can be located in method
>> <SwTxtFormatter::CalcRealHeight(..)> at
>>
>> sw\source\core\text\itrform2.cxx line 1756.
>>
>>
>> I thought that the preferable way to fix this would be to considering the
>> spacing contains above paragraph
>>
>> spacing property and line spacing property as the conditions to determine
>> whether clipping text. e.g.
>>
>> Clipped text if the sum of adding above paragraph spacing and line
>> paragraph spacing is smaller than font size,
>>
>> otherwise do not clip text since above paragraph spacing and line spacing
>> are enough to display the text.
>>
>
> From my point of view this change makes sense.
> If the text of the first line of a paragraph "founds" enough space in the "above
> paragraph spacing", the text should not be clipped.
>
> I had already looked at the patch and it looks ok.
> I will have a deeper look regarding how to determine the value of "above
> paragraph spacing". As far as I remember in some cases depending on certain
> compatibility option, the "above paragraph spacing" is not applied. E.g., if the
> paragraph is the first on a page and compatibility option "Add paragraph and
> table spacing at tops of pages ..." is not checked, the "above paragraph
> spacing" is not applied.
> May be I find a solution to access the already calculated and applied "above
> paragraph spacing".
>
I had a deeper review on the patch.
Please see my comment in the issue [1].
[1] https://issues.apache.org/ooo/show_bug.cgi?id=119476#c5
Best regards, Oliver.
>>
>> Noticed that there is a property named below paragraph spacing, but I'm
>> not sure whether there is a need to consider this one,
>>
>> Do this property impact text clipped in paragraph?
>>
>
> May be - I am not sure.
> Thus, a paragraph could have a "below paragraph spacing" and the first text line
> of the following paragraph could be to small. This would cause clipping, but may
> be the "below paragraph spacing" from the previous paragraph could be used to
> avoid the clipping.
> From my point of view avoid the clipping in this case would also make sense.
> May be my above mentioned further investigation regarding the available space
> above the first text line of a paragraph would solve this, too.
>
> Zuojun, do you know how MS Word will behave in this case?
>
>
> Best regards, Oliver.
Re: Question about text clipping mechanism in word processor
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 20.06.2012 10:47, ZuoJun Chen wrote:
> Hi All,
>
> I'm trying to handle a bug on text clipped in document . See Bug
> 119476<https://issues.apache.org/ooo/show_bug.cgi?id=119476> for more
> details.
>
> After investigation, I have some insights. When paragraph line spacing is
> smaller than font size,
>
> the text contained becomes too large for fit, then AOO will clipped text
> as Incomplete part. The code
>
> for text clipped mechanism can be located in method
> <SwTxtFormatter::CalcRealHeight(..)> at
>
> sw\source\core\text\itrform2.cxx line 1756.
>
>
> I thought that the preferable way to fix this would be to considering the
> spacing contains above paragraph
>
> spacing property and line spacing property as the conditions to determine
> whether clipping text. e.g.
>
> Clipped text if the sum of adding above paragraph spacing and line
> paragraph spacing is smaller than font size,
>
> otherwise do not clip text since above paragraph spacing and line spacing
> are enough to display the text.
>
From my point of view this change makes sense.
If the text of the first line of a paragraph "founds" enough space in the "above
paragraph spacing", the text should not be clipped.
I had already looked at the patch and it looks ok.
I will have a deeper look regarding how to determine the value of "above
paragraph spacing". As far as I remember in some cases depending on certain
compatibility option, the "above paragraph spacing" is not applied. E.g., if the
paragraph is the first on a page and compatibility option "Add paragraph and
table spacing at tops of pages ..." is not checked, the "above paragraph
spacing" is not applied.
May be I find a solution to access the already calculated and applied "above
paragraph spacing".
>
> Noticed that there is a property named below paragraph spacing, but I'm
> not sure whether there is a need to consider this one,
>
> Do this property impact text clipped in paragraph?
>
May be - I am not sure.
Thus, a paragraph could have a "below paragraph spacing" and the first text line
of the following paragraph could be to small. This would cause clipping, but may
be the "below paragraph spacing" from the previous paragraph could be used to
avoid the clipping.
From my point of view avoid the clipping in this case would also make sense.
May be my above mentioned further investigation regarding the available space
above the first text line of a paragraph would solve this, too.
Zuojun, do you know how MS Word will behave in this case?
Best regards, Oliver.