Junicode update vs. JuniusX/JuniusVF

[apikshafiee]

Dear creator of these wonderful fonts, I really appreciate your high level and professional works, just I have faced these issues:

For me, the best font ever was and is Junicode.ttf. Only some characters like  don't include it. Rather than to JuniusX and JuniusVF, Junicode has two preferences:

1. It's really good shaped and well presented in Word as it can be seen in the attached screenshot.
2. it has this ability to stand without any problem when I use paragraph spacing like at least at 12pt.

Where JuniusX and JuniusVF show  very well but are not representing the two mentioned features very well.

Many thanks Yours Ibrāhīm Šafiʿī

[apikshafiee]

[alerque]

I'm pretty sure this is doing to turn out to be a M$ Word bug, not a font bug. I've seen similar things before when following newer OpenType standards (newer is in 1 decade ago instead of 2 decades ago) and with variable fonts.

Can you try printing this and/or seeing what an output PDF looks like? I'm pretty sure you will find the problem is just with the display inside of Word. Not 100% positive of course and there could be a bounding box problem with the font itself, but at least seeing this fresh out of the gate my money is on Word being at fault here.

[psb1558]

Word famously has a problem with clipping, but both Junicode and JuniusX handle that problem in the recommended way, and it works. This problem is different: Word appears to lay down a white background under each letter that it renders. This background appears to be equal to sTypoAscender + sTypoDescender, the numbers that communicate the recommended line spacing for the font. When line spacing is set tighter than sTypoAscender + sTypoDescender, letters of surrounding lines get cut off. This is rather technical, and I don't have any special insight into the programming of MS Word: these are just my observations.

Here's the thing: Junicode sets sTypoAscender and sTypoDescender according to rules that make their sum equal to the font's em-square, and JuniusX sets them according to the rules suggested here, so that sTypoAscender + sTypoDescender are equal to the height of the highest character in the font and the depth of the lowest character.

This is all rather dizzy-making, but the takeaway is this: as long as MS Word goes on drawing those white boxes, both sets of rules will cause letters to be cut off on the display, but in different places. For example, with line spacing set to "at least 12pt," Junicode won't have the bottom of g cut off, but Word will cut off the tops of high characters like A + breve + hook:

The good news is that both fonts will be rendered correctly when sent to a printer or in a PDF.

In the end, the question is which set of rules produces the fewest problems, and that's a tough one to answer when a large number of apps all have their different ways of rendering fonts, and even in MS Word you can set up line spacing in many ways. So far, I've decided to follow current best practices, but no line spacing scheme is without problems, and not all font makers agree on the new scheme. And I've noticed that some people would prefer to have line spacing in JuniusX work like the line spacing in Junicode. I'm open to restoring that behavior if enough people want it.

[apikshafiee]

Dear friends many thanks for your wonderful comments. I got it. here is the result by getting it in PDF format.

1. Junicode
2. JuniusX
3. JuniusVF

[psb1558]

Good, but I don't get what's going on with U+E665. It's in the current Junicode-Italic (in the "legacy" folder on this site).

[kenmcd]

The lower part of the characters is being cut-off by the typoDecender. Windows apps are using the typo settings for line spacing. If you look at TNR for example for the g and the p you will see the difference. Google Fonts has some fairly new guidelines they have been following. https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics I have been meaning to test the "new font" recommendations in various apps. So I can play with this using Junicode Neue ;-) if you do not mind waiting a bit. Got a lot going on the next week or so.

[psb1558]

Thanks for the link, @kenmcd. I'll have a look, and will welcome the results of your experiments. Take as long as you want—I'm playing a long game here.