Issue 107030 - line height calculation should not be used for clipping decisions
Summary: line height calculation should not be used for clipping decisions
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
: 96783 (view as issue list)
Depends on:
Reported: 2009-11-19 09:58 UTC by jiayanmin
Modified: 2017-05-20 11:33 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

the bottom of a glyph is gone (70.53 KB, text/plain)
2009-11-19 09:59 UTC, jiayanmin
no flags Details
fallback font is not "selected" into the font list box (67.71 KB, text/plain)
2009-11-30 02:29 UTC, jiayanmin
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jiayanmin 2009-11-19 09:58:36 UTC
The problem was found from a defect associated with Devanagari text output.
Please see the screenshot included in the attachment, the bottom part of a glyph
is gone. It is caused by a fatal mistake during calculating text height which
always be got by the matrix data of the font selected in advance. If the
selected font can display the characters correctly, every thing is OK. When the
selected font is unable to contain all the characters, a fallback font would be
used to display the characters, but unfortunately, the text height is still
calculated by the original selected font. It's very hard to fix the problem
because of the process of text formatting in sw module. Please refer to the
implementation of the function OutputDevice::GetTextHeight(). What's important
is that sw doesn't know the fallback font when calculating text height.
Comment 1 jiayanmin 2009-11-19 09:59:54 UTC
Created attachment 66186 [details]
the bottom of a glyph is gone
Comment 2 philipp.lohmann 2009-11-19 10:33:01 UTC
pl->hdu: please have a look. Might however be a problem with writer itself and
the way the render text lines.
Comment 3 jiayanmin 2009-11-20 01:37:32 UTC
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.
Comment 4 jiayanmin 2009-11-20 02:29:09 UTC
cc to zhf
Comment 5 jiayanmin 2009-11-20 02:43:14 UTC
also cc to victor21 (Jing Lai) who is a member of i18n team of Symphony development.
Comment 6 jiayanmin 2009-11-20 02:44:52 UTC
zhf (Haifeng Zhang) is my manager. :) He want to track the status of this problem.
Comment 7 jiayanmin 2009-11-20 02:48:45 UTC
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. 
Comment 8 2009-11-20 09:06:18 UTC
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")
Comment 9 2009-11-20 12:40:10 UTC
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.
Comment 10 jiayanmin 2009-11-23 03:34:14 UTC
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. :)  

Comment 11 jiayanmin 2009-11-30 02:29:57 UTC
Created attachment 66404 [details]
fallback font is not "selected" into the font list box
Comment 12 jiayanmin 2009-11-30 02:40:40 UTC
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.   
Comment 13 Oliver-Rainer Wittmann 2009-12-02 12:50:43 UTC
setting target and adjusting priority.

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

Please submit a new issue for your last problem. It is not good to mix several
problems into one issue. Thanks in advance.
Comment 14 jiayanmin 2009-12-03 01:48:04 UTC
>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. :)

>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.
Comment 15 Oliver-Rainer Wittmann 2009-12-03 07:51:40 UTC
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.
Comment 16 michael.ruess 2009-12-03 12:42:48 UTC
I also do not think, that this problem does not show this dramatically. It only
occurs when font fallback is needed.
Comment 17 jiayanmin 2009-12-04 02:11:59 UTC
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.  

Comment 18 jiayanmin 2009-12-11 01:36:36 UTC
What's the status of this issue? Does any one take actions on it? Thanks. :)
Comment 19 Oliver-Rainer Wittmann 2009-12-11 07:23:18 UTC
From my point of view it has been clarified the problem and the proposed solution.
Implementation of the proposed solution has not started, yet.
Comment 20 2010-01-07 11:38:32 UTC
*** Issue 96783 has been marked as a duplicate of this issue. ***
Comment 21 jiayanmin 2010-06-13 09:00:06 UTC
I completely understand the complexity and difficulty of the problem. It seems no 
one working on this issue. :) 
Comment 22 Marcus 2017-05-20 11:33:32 UTC
Reset assigne to the default "".