Created attachment 66186 [details]
the bottom of a glyph is gone

pl->hdu: please have a look. Might however be a problem with writer itself and
the way the render text lines.

I think sd and sc have the same problem too. It would be particularly 
significant for the quality of text format to fix the problem. A reasonable
solution is to calculate the width and height of the text at same time after
calling function OutputDevice::ImplLayout(...). Anyway, the change of the text
format would not be avoidable, so need the input from sw, sd even sc.

cc to zhf

also cc to victor21 (Jing Lai) who is a member of i18n team of Symphony development.

zhf (Haifeng Zhang) is my manager. :) He want to track the status of this problem.

cc to fuxingwang (Xingwang Fu) too. He is another member of i18n team of
Symphony development. :), Sorry, I don't know how to include all the people in
the cc list at same submission. 

I'm sure there must be already an issue for this... the first problem is that the apps seem to clip against 
ascent+descent+some margin. This fails when the ink bounds of layouted glyphs extend beyond these 
typographic suggestions. Especially scripts with vertically stacked glyphs like Thai, Hindi, etc. suffer 
from this.

As you noted the second problem is that even if the requested font's typographic line height would 
perfectly accommodate any combination of its layouted glyphs then still all bets would be off if glyph 
fallback was involved.

So the root cause of these individual problems is that the clipping area is calculated too simplistically. 
I'm not even sure why individual lines get clipped? AFAIK an intermediate VirtualDevice is involved to 
prepare a line. Maybe painting directly would be beneficial.

Reassigning to the WriterEngine expert.

> Sorry, I don't know how to include all the people in the cc list at same submission.

Just separate the people in the CC-line by a space (e.g. "victor21 zhf fuxingwang")

FYI, regarding the first issue there was an interesting thread on the OpenType mailing list (subject line 
was "Vertical Metrics Inconsistencies") which impacts other related applications too.

Line size calculation is very important for text formatting. The glyph is not
allowed to extend outside the size of the line in order to avoid conflict
between two lines. 

For the individual problem I showed in the attachment, the root cause is that
fallback font is used to display the glyphs while original selected font is used
to calculate the height of the clipping area. That could be proved by debugging.
And it's also confirmed by a simple experiment. When selecting a right font for
the Devanagari character, the chracters can be represented correctly. But when
another font is selected, the problem occured.

My proposal solution is to re-implement the calculation of height of line in
consideration of fallback font. I think the best way is to calculate the width
and height of line at the same time after calling OutputDevice::ImplLayout(...).
That means merging OutputDevice::GetTextHeight with OutputDevice::GetTextWidth.
The current implementation ofOutputDevice::GetTextHeight is really too naive. :)  

Created attachment 66404 [details]
fallback font is not "selected" into the font list box

Another problem could be associated this one. Moving the caret into the text
which is represented by the fallback font, the family name of the fallback font
will not be selected in the font list box. Please refer to the graphic in my
attachment. The font used to diaplay the text should be consistent with the one
in the list box as the behavior of MS office. It's time to re-consider the font
setting during text formatting.   

setting target and adjusting priority.

OD->MRU: Any input from your side on this issue?

OD->yanminjia:
Please submit a new issue for your last problem. It is not good to mix several
problems into one issue. Thanks in advance.

yanminjia->MRU
>Any input from your side on this issue?

I'm also expecting the responding because I think it's really a important
problem which is affecting the quality of documment output of OOo. :)

yanminjia->OD
>Please submit a new issue for your last problem. It is not good to mix several
>problems into one issue. Thanks in advance.

No problem, I will file another issue for the last problem. But I think the two
problem are introduced by the same root cause. So don't ignore the other while
fixing this one.

OD->yanminjia:
From my point of view this issue is not as serious as you are presenting it. The
defect occurs when the intended font is not available and a font fallback takes
place. Thus, in general the line height calculation works as expected.

I also do not think, that this problem does not show this dramatically. It only
occurs when font fallback is needed.

yanminjia->MRU, OD

Yes, it's not a serious problem for Latin script because most fonts contain the
glyphs of Latin character. So font fallback would not be heavily depend on to
display Latin character. But it's not so fortunate for other script because most
fonts are available only for a single script except Latin. So font fallback is
really significant for other script. It's not a good idea to expect users always
select the right font to display the text. Anyway, it should calculate the text
height depending on the actually used font.  

What's the status of this issue? Does any one take actions on it? Thanks. :)

From my point of view it has been clarified the problem and the proposed solution.
Implementation of the proposed solution has not started, yet.

*** Issue 96783 has been marked as a duplicate of this issue. ***

I completely understand the complexity and difficulty of the problem. It seems no 
one working on this issue. :) 

Reset assigne to the default "issues@openoffice.apache.org".