Writer: fonts diacriticals

Libre Office v6.0.5.2 (64). HP-Q130. Intel HD Graphics 1920x1080.
I guess this is one for the Typographers!

I have installed an Irish font Gadelica. The language has diacriticals in the form of a dot above certain consonants.
In capital letters the dot is cut off - only the lower half of the dot is shown. This occurs in all font sizes. It occurs when viewed in Print Preview.
I have tried changing paragraph spacing and line spacing. No change.

When I export to pdf, the full dot is shown.

If this was a fault in the design of the font surely the problem would show up in the pdf file?

Have you checked if Format>Paragraph Line Spacing in Indents & Spacingtab is set to Fixed with too small a size? Same check on the current paragraph style?

I have checked the letters Ḃ Ċ Ḋ Ḟ Ġ Ṁ Ṗ Ṡ Ṫ with several fonts in LO 6.0.4 in Windows 7. No problem as described (only in Deja Vu fonts the dot above is raised too much, in my opinion, but still not cut off). Looks like an issue about the particular font.

I set big line and paragraph spacings. Yes it looks like a problem with the font itself, but there are inconsistencies in the rendering.

The problem is with the font. Specifically the WinAscent setting.
LibreOffice uses this as the upper limit of any glyph.
You can see how this works by highlighting some of the text.

.
I ran into this recently when testing OpenType features such as stylistic sets.

.
You can see by the highlighting that those swashes are outside the box.
What is odd is that the zoom level affects the display.
At 150% (this image) you can see only the larger text looks correct.
At 200% nothing looks correct.
At 100% all looks correct.

I tried zooming on your font and it did not help.

Note that Word 2016 has the same issues.

I opened the font in FontCreator and took a look.
In the image below you can see where your characters are being cut-off at the WinAscent line.

image description

.
More advanced applications do not have this issue.
Both fonts look fine in QuarkXPress. See image below.

.

Yesterday while testing font families I found a similar issue with a new font family.
Libre Franklin has been forked to become Public Sans.
The new developer adjusted the font metrics to “normalize” them.
This resulted in the descenders being cut-off of for example the lowercase “g” is what I noticed first.
Same issue on the bottom.

Not sure why your font was designed like this.
It is my understanding that there is no easy fix.

.
If this answers your question, please check the checkmark at left.

.
Not sure if this is just a LO on Windows issue.
Could some Linux and Mac users please test?

I got the font here:
http://www.leabhair.ie/sob/gadelica/index.html
http://www.leabhair.ie/sob/gadelica.zip

.
Update
WinAscent and WinDescent are only used by Windows.
They define the upper and lower limit of the glyph on Windows.
So since WinAscent on this font cuts right through the diacritics they appear cut-off.
Export to PDF uses a different rendering engine so it does not have this issue.

.

Just checked on my Fedora Linux. Truncation is not as bad as in OP’s screenchots. Glyphs extend outside the box but to get truncation you really need to request queer zoom factors like 437%. Rather “commensurate” factors like 150% or 300% display fine.

The issue seem to be an interaction between a faulty-designed font and font rendering engine. All engines are probably not equal.

Anyway, congratulations Libre Training for finding the explanation.

Thanks for testing on Linux.
After posting above I did find in the FontLab docs that WinAscent and WinDescent are only used by Windows.
Linux and Mac use different settings.
So a font can have different results on the different operating systems.
Could be this font was created on Linux or Mac and was not tested on Windows.
Seems to be the case.

The problem must be with Gadelica. Is there any way to modify it to bring the dot below the upper limit?
Linux Mint and Win truncate at all font sizes. There are differences between Win and Linux.
In Mint if I do a print preview and then toggle back to edit mode the truncation is gone!
If, after typing a Gadelica character, I change font and then type a letter or just a space the same occurs, and all charcs drop slightly.
Outlining the characters shows half the dot still above the upper limit.

Scrolling down to a new page and back also gets rid of the truncation. But not in Windows.

I contacted the font author. He accepts that the dot is partly outside the “theoretical” boundary he feels that LO should display it fully. He feels that essentially it is an LO font handling issue. The problem is not present in Abiword, nor in .pdf (I don’t want to use Abiword as it doesn’t have other features that LO does).
Other fonts such as Seanchlo have the same problem.

Strange! In my understanding, the various bounds are strict clipping limits. The limits are “publicly” set so that the font renderers can quickly arrange the bounding boxes in a line for the purpose of of justification. Again in my understanding, nothing should show outside the bounding box (here for the benefit of drawing applications). I don’t know what standards say about font description, but i think that glyphs should not extend beyond their bounding box.

That sounds reasonable, but it it a universally accepted standard? And does Libre Office conform?
How do I view the bounding box around a character? Does outlining a character show these bounds?
The effects differ between Windows and Linux, so is it the system or the app that determines if something outside the box will display?

To be honest, no idea. I think outlining a glyh cause the bounding box to swell a bit because you draw lines around the existing shape. Consequently, it is likely that every font renderer processes that differently, which could explain the discrepancies. When I have time, I search the net to find info on font definitions and standards.