Other Blues for Superscript / Subscript ?

mauro sacchetto

I fixed the Blue Values ​​(baseline, x-Height, C-Height, Ascender).
I noticed however that the alignment for Superscript and Subscript was imperfect. I followed the same logic, but entering the values ​​in Other Blues (I saw that some Adobe fonts proceed in this way). However some glyphs remain not perfectly aligned (<v> and <w> in Superior, <m> and < n> in the Inferior).
Does it depend on whether I set wrong values, or that there is an overlap or excessive closeness between Blue Values ​​and Other Blues, or that my process is wrong?
I enclose the values ​​and, if someone would kindly give us a look, the otf.



file .otf: https://www.dropbox.com/s/8vepc10r3cs3w8w/Test-Regular.otf?dl=0

Thomas Phinney

You can certainly use OtherBlues for this, and in fact you must if you want to have more than seven pairs.

Zones must be at least ((2 x BlueFuzz) + 1) units away from each other. So even with a BlueFuzz of zero, it is invalid to have another Blue Zone starting at the same coordinate another one ends. Look at the coordinate 693 which appears in both BlueValues and OtherBlues. With your current BlueFuzz of 1, these values need to be at least 3 units apart.

mauro sacchetto

But if are the glypghs placed in contiguous areas? In fact it is normal that superscript numbers are close to uppercase or ascending ... In this case, which strategy should I use? Only a very large area?

Thomas Phinney

There isn't a viable solution for that in the PostScript hinting model. You are not allowed to have Blue Zones that directly abut each other.

That said, surely you could tweak things to move them a single unit apart, no? And then set your BlueFuzz to zero, and you would be OK. (Assuming you do not need BlueFuzz, which most of us do not.)

mauro sacchetto

Ok, life is nice even with BlueFuzz = 0    
now I try to change the parameters to comply with rules and restrictions. Let's see what comes out ...

Thomas Phinney

Basically BlueFuzz is there to allow your Blue Zones to grab things that are some small number of units outside the zone. If you have outlines of uncertain consistency, this could be handy. But for carefully-crafted outlines, it is usually unnecessary.

mauro sacchetto

I see. My trouble is with some super- sub-script glyphs, which are not correctly aligned in their baseline...

mauro sacchetto

I reviewed all the values and tried more solutions to improve superscript and subscript rendering.

I think I understood the general logic, even if sometimes I proceed by trial and error and spent a few hours finding the solution. However in both cases (sub and super) there are glyphs that continue to be misaligned. The v and w at certain zoom sizes with Adobe Acobat Reader appear to break down the baseline below, while the x and z appear conspicuously smaller.

At this point I don't understand if the responsibility is mine, because I continue to enter the wrong parameters, or if there is some problem with the bad design of the font.

I attach the new parameters and the latest version of the font, in case someone was kind enough to take a look and suggest me if I am still making mistakes or if it is necessary to change the glyphs by hand.

Thanks a lot!



otf: https://www.dropbox.com/s/4ym9kwipaavmb9g/Test-Regular.otf?dl=0

Jens Kutilek

What are your (-38, -21) and (682, 690) zones for? I couldn't find any glyphs that match them.

I think what you are trying to do will not work with PostScript hinting. For example, the zone just below the x-height is way too close to the x-height and will mess up the rendering of the lowercase alphabet, while trying to fix the alignment of the rarely used superscript glyphs. I would just ignore those and try to get along with zones at descender, baseline, x-height, small-cap height and cap height.

If you want more control, TrueType hinting may be the solution. There you can control what glyphs should be attached to what zones, and control the positions of the zones relative to each other for every pixel size.

mauro sacchetto

The zone (-38, -21) would be the superior area for subscripts, and (682, 690) the superior area for superscript.
In BlueValues there are: baseline (-18 ,0), x (416, 436), smallcaps (467, 483), C (693, 711), ascender (750, 750).
In OtherBlues in order: subscript bottom (-325, -312), descender (-222, -222), subscript top (-38, -21), superscript bottom (390, 402) and superscript top (682, 690).
Are there values diffusely wrong?
You write: « the zone just below the x-height is way too close to the x-height». 
And what should be a suitable distance between the glyph border and the BlueZone?

Thomas Phinney

Those zones should be OK, given a BlueFuzz of zero or one. But of course if you have glyphs that stick out past the desired zone, either you need to tweak the glyph, or... something.

Note that as the very purpose of BlueFuzz is to catch things that extend beyond the zone, reducing BlueFuzz from one to zero might not help too much. But at least you could then decide which of the two zones to extend to take up that slack, in each case: both, neither, or extend one by two units.

Jens Kutilek

The distance of the zones around the x-height may technically be allowed, but in your font the problem is that a lot of lowercase glyphs' upper hints are in both zones, causing ugly distortions.


You could work around it if you use a ghost hint on top of the o, so that only the outer contour is influenced. It looks better in total, but of course the stem is less well defined that way.

The subscript top zone is in OtherBlues in your screenshot, but it should be in BlueValues as it is a top zone. That said, I think your subscript glyphs sit far too low, completely below the baseline. Usually their vertical center is around the baseline.

You may have too many StemSnap entries, which makes the fonts look more irregular.

And the StdHW and StdVW values should not be repeated in the StemSnap... lists as far as I know.

And then some glyph hints are less than ideal, e.g. the n looks bad because it has one hint across all its height. When you remove that, it looks much better.

mauro sacchetto

I followed your advices rearranging the glyphs, redoing the hinting, reducing the number of StdHW and StdVW values ​​and replacing subscripts "higher". It seems to me that the problem has been solved.

The only thing on which I am perplexed (but as you know I am very inexperienced), regards the fact that, as @JensKutilek writes

the StdHW and StdVW values ​​should not be repeated in the StemSnap

In fact, we read for example on pag. 3 of

https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5049.StemSnap.pdf

about the StemSnap (H, V) values ​​which

One of there should be the same as the corrisponding StdWV or StdHV array entry

Did I misunderstand myself that one of those values, the more or less "dominant" one, should be taken from the array and repeated in the StdWV or StdHV fields?

mauro sacchetto

PS
A last question, You write:

The subscript top zone is in OtherBlues in your screenshot, but it should be in BlueValues as it is a top zone. 

Do BlueValues ​​contain positive values ​​or top zones? For inferior, in fact, even the top zones have a negative value...

Jens Kutilek

mauro sacchetto said:

In fact, we read for example on pag. 3 of

https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5049.StemSnap.pdf

about the StemSnap (H, V) values ​​which

One of there should be the same as the corrisponding StdWV or StdHV array entry

Did I misunderstand myself that one of those values, the more or less "dominant" one, should be taken from the array and repeated in the StdWV or StdHV fields?

You are right, I misremembered this.

Jens Kutilek

mauro sacchetto said:

PS
A last question, You write:

The subscript top zone is in OtherBlues in your screenshot, but it should be in BlueValues as it is a top zone. 

Do BlueValues ​​contain positive values ​​or top zones? For inferior, in fact, even the top zones have a negative value...

BlueValues are top zones plus the first entry, the baseline zone. All other bottom zones should go into OtherBlues.