Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||line height calculation should not be used for clipping decisions|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||hdu, issues, laiyijing, michael.ruess, outshade, zhf|
|Target Milestone:||OOo 3.x|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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 firstname.lastname@example.org 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 email@example.com 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? 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.
Comment 14 jiayanmin 2009-12-03 01:48:04 UTC
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.
Comment 15 Oliver-Rainer Wittmann 2009-12-03 07:51:40 UTC
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.
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 firstname.lastname@example.org 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. :)