Bug Hunting Session
Bug 42000 - WRITER: Character font cap height is not displayed on capital letters
Summary: WRITER: Character font cap height is not displayed on capital letters
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: MacOS-Wishlist 56932 Font-Rendering
  Show dependency treegraph
 
Reported: 2011-10-19 10:33 UTC by Emir Sarı (away)
Modified: 2019-04-20 16:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Letters Й and Ğ with fonts Helvetica and Lucida Grande (129.04 KB, image/png)
2011-10-19 10:33 UTC, Emir Sarı (away)
Details
Capital letters İ, Ö, Ü in NeoOffice, respectively (88.31 KB, image/png)
2012-11-16 17:42 UTC, Emir Sarı (away)
Details
Letter ح in 4.0.0.0 alpha1 (8.61 KB, image/png)
2012-11-22 21:03 UTC, Emir Sarı (away)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emir Sarı (away) 2011-10-19 10:33:39 UTC
Created attachment 52528 [details]
Letters Й and Ğ with fonts Helvetica and Lucida Grande

Hello,

This problem is present for several versions of Libreoffice and continues even when Libreoffice was not around at all. 

When I try to type a Turkish character like capital İ or Russian capital Й with accent marks on it Writer does not display the accent mark. The accent mark actually exists there, it is only visible if I select the word and continue selecting to the upper line, or when I select "Print Overview" from the toolbar. It also prints, but this is a very annoying visual glitch. 

The problem is present on Mac OS X. It does not affect other Libre products except Writer.
Comment 1 Emir Sarı (away) 2011-10-19 10:35:05 UTC
My humble opinion is, I guess it is time to switch to CoreText. With outdated ATSUI functions I am even not sure if it is worth to fix this bug.
Comment 2 Emir Sarı (away) 2012-02-15 04:42:28 UTC
Confirmed with 3.5.0. The issue is still present.
Comment 3 Emir Sarı (away) 2012-09-02 17:21:53 UTC
Still reproducible with 3.6.1.2.
Comment 4 Roman Eisele 2012-09-25 18:14:19 UTC
Bug was never confirmed by an independent reviewer, therefore reset Status to
UNCONFIRMED.

(No offence -- this does not mean that I doubt the existence of this bug --
when status is UNCONFIRMED, the chance is even better that a bug wrangler will
try to reproduce this issue or search for duplicates, while with Status NEW the
bug will probably just be overlooked.)
Comment 5 Uwe Altmann 2012-10-19 14:53:59 UTC
Can not reproduce with LO 3.6.2.2 on Mac os 10.6.8. (copied and pasted unformatted title of attachment). Is it still present on your system?

And I can btw not understand the meaning of "…and continues even when Libreoffice was not around at all."
Comment 6 Emir Sarı (away) 2012-10-19 19:03:00 UTC
(In reply to comment #5)
> Can not reproduce with LO 3.6.2.2 on Mac os 10.6.8. (copied and pasted
> unformatted title of attachment). Is it still present on your system?
> 

It should be reproducible with the system default Helvetica font. Copying/Pasting should work fine, but typing does not work. It is still visible under Print Preview, but under editing environment we have to select one or two lines to above to be able to see the missing parts. And it sometimes leaves artifacts when scrolled down. 

> And I can btw not understand the meaning of "…and continues even when
> Libreoffice was not around at all."

I meant the OO.org era. :)
Comment 7 Emir Sarı (away) 2012-10-23 18:26:48 UTC
Issue is still present on the latest daily build.
Comment 8 Roman Eisele 2012-11-16 16:03:26 UTC
At least partially REPRODUCIBLE with LibreOffice 3.6.4.1 (Build ID: a9a0717)
on Mac OS X 10.6.8. There are strange things going on with the drawing of accents on Mac OS ;-)

However, a detailed explanation of my findings will take some time and explaining screenshots etc., and I have to leave my computer now, so I will add the explanation later. [If I happen to forget about it -- homo sum, humani a me nihil
alienum puto --, please ping me!] For now this notice should be sufficient
to prevent this report from being closed etc.

Resetting the version number to the first version which is known to contain the problem (3.5.0). We will check even earlier versions later.
Comment 9 Emir Sarı (away) 2012-11-16 17:39:58 UTC
@Roman Eisele,

Thank you very much for confirming my bug report. 

This happens with mostly core system fonts, like Helvetica and Lucida Grande. I think you meant that by "partially reproducible". 

And one interesting detail, in NeoOffice, which uses Apple's CoreText rendering, I can still reproduce this issue. So it is not something about text rendering I presume, it is a core OO/LO bug. 

Kind regards,
Comment 10 Emir Sarı (away) 2012-11-16 17:42:17 UTC
Created attachment 70167 [details]
Capital letters İ, Ö, Ü in NeoOffice, respectively
Comment 11 Emir Sarı (away) 2012-11-22 21:03:47 UTC
Created attachment 70456 [details]
Letter ح in 4.0.0.0 alpha1
Comment 12 Emir Sarı (away) 2013-07-24 12:33:48 UTC
Issue somehow still persists. But behaviours are more acceptable now, accents get drawed automatically in a few seconds, even firstly glyph is drawn without the accents.
Comment 13 Emir Sarı (away) 2013-07-24 12:35:09 UTC
And the issue is mostly present with Helvetica and Lucida Grande fonts.
Comment 14 Khaled Hosny 2013-07-24 12:49:42 UTC
Without checking the code, this looks like the effect of clipping, we are properly clipping at typographic ascenders/descenders which usually don’t take accents into account.
Comment 15 Khaled Hosny 2013-07-24 13:00:31 UTC
I meant probably not properly. Clipping at typographic ascender/descender (OS/2 TypoAscent/Descent or hhea Ascender/Descender) is not proper of course, the proper setting is OS/2 WinAscent/Descent.
Comment 16 QA Administrators 2015-04-19 03:20:49 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2016-09-20 09:24:19 UTC Comment hidden (obsolete)
Comment 18 eisa01 2018-03-09 22:38:50 UTC
This is still present, but if I alt-tab to another program and go back, the rendering is fixes itself.

Tested with Russian letter Й using Helvetica

This is also inherited from OOo

Version: 6.1.0.0.alpha0+
Build ID: fb29e6eeeaad5255bb924ff59162a83ed80bfb0a
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-03-09_03:22:00
Locale: en-US (en_US.UTF-8); Calc: group
Comment 19 QA Administrators 2019-03-10 03:20:43 UTC Comment hidden (obsolete)
Comment 20 eisa01 2019-04-20 16:55:09 UTC
This is still present

Report: Press shift+q to write Й using Russian keyboard
Note: the tilde is cropped, but as soon as you press enter for a new line, the rendering becomes correct

Version: 6.3.0.0.alpha0+
Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded