Bug Hunting Session
Bug 104846 - The bottom edge of certain glyphs are clipped (using Linux Libertine G)
Summary: The bottom edge of certain glyphs are clipped (using Linux Libertine G)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta2
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering HarfBuzz-regressions
  Show dependency treegraph
 
Reported: 2016-12-21 18:33 UTC by Volga
Modified: 2018-12-25 05:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
See what I have seen (142.08 KB, image/png)
2016-12-21 18:35 UTC, Volga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2016-12-21 18:33:19 UTC
Description:
When I get an ODF sample file from http://www.numbertext.org/linux/ I found several glyphs are clipped with Linux Libertine G.

Steps to Reproduce:
1. Download fontfeatures.odt from above website
2. Open with LODev Writer

Actual Results:  
On this document gf, gfi, gj ligatures were clipped their bottom edge.

Version: 5.3.0.0.beta2
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: group

This problem also appraing to me after I enabled OpenGL.

Version: 5.3.0.0.beta2
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: group

Expected Results:
LibO shouldn’t clipp any glyphs for this file. Compare with: http://www.numbertext.org/linux/fontfeatures.pdf


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Volga 2016-12-21 18:35:08 UTC
Created attachment 129851 [details]
See what I have seen
Comment 2 Volga 2016-12-21 18:58:37 UTC
(In reply to Volga from comment #0)
> LibO shouldn’t clipp any glyphs for this file.

This problem should’t happen until the glyph is touching the edge of frame, text box, page, shape and table.
Comment 3 V Stuart Foote 2016-12-21 21:07:41 UTC
Confirming the clipping on Windows 8.1 Ent 64-bit en-US with both OpenGL and default rendering with the new HarfBuzz layout
Version: 5.3.0.0.beta2 (x64)
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: CL

However, on current master [1] with OpenGL enabled the Graphite glyphs are no longer clipped. With default rendering they are clipped on the bottom edge.

Also with new layout, with OpenGL the extra high Graphite glyphs seem to be sensitive to the "spacing to contents" of the table cell.

To demonstrate, open with OpenGL enabled on current master and locate the table with the example liga row. 

The Graphite ligatures on the last row are clipped.

Then, grab the right edge of the table and drag it wider by a character or so. Notice the glyphs for the ligatures for gf, gfi, will show their full descenders. While glyphs on the bottom are clipped.

Drag it wider and when the gy ligature is brought up--the entire line of glyphs is again clipped.

So, not sure this is a shapping issue for the Graphite fonts, or an issue with the table cells and the way "spacing to border" is applied to glyphs with over height ascenders and descenders. 

=-ref-=
[1]
Version: 5.4.0.0.alpha0+
Build ID: 36750bc977b3210b23b7822abd395b30a78af6f5
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-12-21_00:18:41
Locale: en-US (en_US); Calc: CL
Comment 4 Volga 2017-01-15 15:56:05 UTC
(In reply to V Stuart Foote from comment #3)
> So, not sure this is a shapping issue for the Graphite fonts, or an issue
> with the table cells and the way "spacing to border" is applied to glyphs
> with over height ascenders and descenders. 

Since bug 105346, I’m sure this is an issue for glyphs with over height ascenders and descenders.
Comment 5 V Stuart Foote 2017-01-15 17:23:59 UTC
(In reply to Volga from comment #4)
> Since bug 105346, I’m sure this is an issue for glyphs with over height
> ascenders and descenders.

Well of course, but the issue is not with the glyphs alone but with the object that contains them and its rendering to canvas. The ligature samples here are held in a paragraph within a table cell. Only glyphs along the bottom edge of the table cell are clipped.  

Unlike in bug 105346 neither scrolling canvas off the page and back, nor zooming the canvas in or out affects the clipping that occurs for glyphs positioned at the bottom edge of the cell.

The same glyphs copied to a paragraph are clipped, but that is transient and cleared by canvas refresh or zoom.

Believe there are different rendering actions between table cell content and simple paragraph content--the rendering of table cells is the issue here.
Comment 6 Khaled Hosny 2017-03-05 00:37:21 UTC
This is a font bug; the font has glyphs with large descenders that goes below the font clipping metrics (usWinDescent of the “OS/2” table). The font has to be fixed.
Comment 7 V Stuart Foote 2017-03-05 15:45:15 UTC
(In reply to Khaled Hosny from comment #6)
> This is a font bug; the font has glyphs with large descenders that goes
> below the font clipping metrics (usWinDescent of the “OS/2” table). The font
> has to be fixed.

I don't doubt the metrics to be bad, but there still is an issue with composing the table with the OpenGL rendering.  Try the STR from comment 3, restated here.

1. Download László's Graphite "fontfeatures.odt" sampler [1]
2. Open with recent build of master or 5.3.1
3. With OpenGL rendering enabled
4. scroll to the first tables row holding the liga examples
5. zoom to 400% and pan to show the "Result column" ending with the "gf" ligature
6. note that glyphs on the bottom row of the table cell are clipped
7. "adjust the table column" by grabbing the right edge and dragging
8. drag wider to bring the "gfi" and "gj" ligature result up a line
9. note glyphs that had been clipped, are fully formed
10. drag narrower to push back down and they are again clipped.

11. close document, and disable OpenGL rendering restart with Default rendering
12. repeat opening and zoom & pan to the liga row
13. the "gf", "gfi", and "gj" ligature results are clipped regardless of position--so different handling of layout between the Default rendering and the OpenGL rendering.

So, rather than just the font metrics which are bad, there is a DirectWrite/Direct2D aspect here in composing to canvas.  Not sure we can entirely NOTOURBUG this--at the least it is something to test against when the DirectWrite calls are eventually refactored.

=-ref-=
[1] http://www.numbertext.org/linux/fontfeatures.odt
Comment 8 Volga 2017-03-16 08:29:01 UTC
Is there anyway to make such glyphs not being clipped?
Comment 9 Costas 2018-12-23 01:41:18 UTC
I think this should be revisited, because the fonts print exactly as intended and in PDF too even if they don't display properly (even in current stable version). 

With openGL on, it requires a screen refresh (even by scrolling beyond the character) to display the ligatures but then they dissappear again randomly. 

Since openGL was not on by default, I spent a considerable amount of time trying to find out why the ligatures were not displaying properly, and I was in the process of opening a new bug.

It makes me wonder if other fonts (complex languages) have the same problem.

I tried to find out who to contact for the font but cannot find who is responsible for maintenance of th G version. :(
Comment 10 Volga 2018-12-25 05:02:26 UTC
Costas, you can contact him with this email site: nemeth@numbertext.org