Created attachment 129851 [details]
See what I have seen

(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.

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

(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.

(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.

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.

(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

Is there anyway to make such glyphs not being clipped?

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. :(

Costas, you can contact him with this email site: nemeth@numbertext.org