Bug 152358 - Diacritics above aleef intersect characters / bottom diacritics on previous line
Summary: Diacritics above aleef intersect characters / bottom diacritics on previous line
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering CTL
  Show dependency treegraph
 
Reported: 2022-12-02 15:22 UTC by Eyal Rozenberg
Modified: 2024-08-03 09:15 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
A few examples of diacritics overlapping previous-line contents (11.44 KB, application/vnd.oasis.opendocument.text)
2022-12-02 15:22 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-12-02 15:22:07 UTC
Created attachment 183962 [details]
A few examples of diacritics overlapping previous-line contents

The handling of (Arabic) diacritics is such, that in some cases and with some fonts, diacritics from one line intersect/overlap content from another line - either diacritics or actual characters.

One example of this is the relatively-popular Arabic font family KacstBook, which is even under consideration for being our default Arabic body font (see issue 150481): Diacritics over an aleeph - a tall letter - easily interfere with the previous line, in different scenarios and with different language nad font choices for the previous line. 

The attached document exemplifies this for a few cases. (The text doesn't make sense, think of it as gibberish; I only used it to get certain things to align.)
Comment 1 ⁨خالد حسني⁩ 2022-12-02 20:03:49 UTC
This a font bug, the marks are placed so high they exceed the line ascender and go into the above line.
Comment 2 Eyal Rozenberg 2022-12-02 21:10:11 UTC
(In reply to خالد حسني from comment #1)
> This a font bug, the marks are placed so high they exceed the line ascender
> and go into the above line.

Ok, sure, but don't we have logic to dynamically determine how high a line needs to be based on the characters it actually has?

... hmm. On second thought, maybe that might not be such a great idea, because it would make line heights non-uniform in a paragraph. Well, ok, never mind.