Junicode-Regular.otf not correct size/shape compared to ttf version or older version of otf

[Sunspark-007]

Backstory: I tend to compare ttf and otf versions of fonts to see which one renders better, and I sometimes compare different versions of them because I have noticed that with other fonts that when workflows change a lot can change. For example, the loss of truetype bytecode hinting, etc.

On my device I had version 1.053 of Junicode Two Beta.otf installed. Took a look at 2.206 tonight and noticed a difference right away. My observation, the regular weight ttf version of 2.206 maintains similar glyph shape and height as the old beta otf (good!), and is comparable to the medium weight of the 2.206 of the otf as well. However, the 2.206 regular otf is taller at a given size and more condensed. The other 3, have shorter x-heights and an o will be more round compared to the otf of 2.206 regular weight which looks more oblong.

I feel that they should all be the same height and shape.

This is on an Android device with the bytecode interpreter and anti-aliasing turned on.

The below image is from Windows, so the rendering isn't going to be the same as Android's, but even here you can see differences.

Lots of oddities.. capital M has a break/fracture in the left leg for bottom 2 but not top 2. Z lost the serif curve on 2.206 otf regular. A is shorter on 2.206 otf regular but matches the height of B, etc. on the first two. The crossbar on the H on 2.206 otf is lower than the first two which has it horizontal in the middle, etc. and it also looks narrower. The weight in general looks lighter. Basically, it doesn't look like the same font anymore, too many changes.

Old otf (and mostly what you get with the ttf version): New otf:

[psb1558]

The differences you're seeing, I'm pretty sure, are entirely due to the beta version not being hinted and version 2.206 being hinted with psautohint. The addition of alignment zones can cause the x height to change at certain resolutions, while the use of flex hints can cause the curve at the bottom of the Z to get flattened out at low resolutions. Hinting will also change things like the exact height of H's bar and the width of various strokes.

Not much to do about this, except to strip out the hints (which you are welcome to do). That said, I did spot one actual problem when I was going over your points: the top of A just barely escapes the cap height alignment zone. I've fixed this, and it will be correct in version 2.207 (probably some time next month).

[Sunspark-007]

Do you think that the bottom of the "e" curve goes too low compared to the floor set by the l, or this is intentional?

It's interesting that the autohinted TTF version looks more like the old version compared to the new OTF which is taller.

It seems like these are intentional changes.. that in the body text sample that it actually is meant to be taller and and/or lighter weight.. I find myself thinking that the presentation is different enough that they could be two different fonts because the otf is that much taller.. it feels like it was stretched upward but was really meant to be a little shorter.

I wonder if anyone will register an opinion between the different x-height appearance of the ttf and otf? Probably most people will never compare the two, but seeing the body text sample here would work for comparison.

[psb1558]

ttf and otf fonts employ vastly different hinting systems, and the two autohinting systems I use (ttfautohint and psautohint) predictably produce different results. In the case of "le" both will align the bottom of e with the baseline at low resolutions, but they will differ as to what triggers this alignment.

If it means something to people that otf and ttf versions should look more alike, I know one thing to try: ttfautohint can read the blue zones from an otf font and take those into account when it produces TrueType hints. I don't know how many of the differences you've observed this will address, but I'll give it a try and see what happens. Of course, if this does anything at all, it will make the ttf version more like the otf version, not vice versa. I don't know of a way to make the otf font look more like the ttf.

The ultimate fix is to manually hint all the fonts--and in fact I do manually hint the variable fonts (which I recommend to everyone able to use them). But manually hinting 152 static font files with circa 2600 hintable glyphs each is more than I can take on.

[kenmcd]

The only difference is the hinting, or lack-of in what you were using. This is the current version (v2.206) with the hinting removed (OTF and TTF). One of these will probably look like your old version. Junicode-Regular.v2.206.dehinted.zip

I used FoundryTools-CLI to dehint them. Took about five minutes. (note: the I did not edit the TTF version string so it still says ttfautohint)

[psb1558]

I was mistaken in my last post. ttfautohint doesn't read blue zones from an otf file, but rather derives them from a ttf font. So that is not a fix.

If the difference between otf and ttf hinting is a problem for you (it is not a problem for me), I suggest following @kenmcd's advice and simply remove the hints.

[Sunspark-007]

I have interesting feedback to add about the hinting. This is the issue.. the font itself is fine.. how do I know this? Just now for fun, I was looking at the STIX Two fonts which come in ttf ttfautohint, otf AFDKO autohinting, and variable ttf unhinted. Threw all three in my reader, and all 3 look different. It is just like my initial concern with Junicode, the STIX ttf looks short (and the worst visually), the otf looks taller, and the variable looks intermediate and probably the most pleasing in terms of glyph shape on this pentile display.

For additional fun, I will take a look at Ken's and the variable version.

[Sunspark-007]

Ok, I have some screenshots.

1- ttf dehinted - blurrier "a" compared to otf dehinted, loosest character spacing 2- otf dehinted - "e" crossbar is higher than variable making the open space slightly smaller, "a" is nice and clear. medium spacing 3- variable official, manually hinted - "g" is shorter than the dehinted otf which is taller, tightest character spacing

Probably I should also have turned off the bytecode interpreter as well as this can work very well for some fonts that have bad or nonexistent hint shaping, but most people won't have this switch at all.

I'm thinking of the 3, the dehinted otf is probably the best looking one, but it could benefit from having a bigger "e".

Also that given that most of the time on Linux (and Mac especially), it doesn't at all care about hints in OTF, maybe the best thing to do for this file format is to not have it be hinted. The higher resolution a display is, the more ideal to becomes to not use anti-aliasing.

ttf dehinted

otf dehinted

variable official

[psb1558]

Interesting, but I don't see an issue that I can address.

[Sunspark-007]

On my reader, it turns out that most (but not all) of the fonts I have look better with the bytecode interpreter turned off, sometimes significantly so. Even easier to see if one turns anti-aliasing off while flipping bytecode on and off. Characters get taller or shorter, wider or narrower, sometimes a glyph position will move slightly up or down, lines might be a single pixel wide or they might be thicker, etc.

Variable font Junicode looks pretty similar to the unhinted one if bytecode is turned off, so I am closing the issue. For any given font, I don't think the issue is the glyph shape, but rather what is the module doing in terms of fitting it?

It means if one REALLY wants to be sure any given font is rendering well on their display, they need to define configuration settings specifically for that font--easy enough to do on Linux, not so much on Windows or Mac.