After I created superior and inferior numbers (not originally present) in a font to handle fractions, I receive the message:
`Alignement zone height in BlueValues/OtherBlues array is too big for BlueScale`.
So, the result is a uncorect Private Dictionary.
What exactly does it mean?
And what kind of action should I take to set the correct values?
Thank you
0
Comments
Perhaps you added a blue zone while working on the superiors and inferiors, or extended the size of an existing blue zone? Or an app might have helpfully done this for you?
Either you need to reduce the thickness of the problematic blue zone (overshoot zone), or increase the BlueScale. You don't mention what tool you are using, so how you would do either is unclear.
BlueScale may be expressed as an integer value in font units (relative to the UPM), or as a proportion of the em. So "36" may be the same as "0.02778"; luckily these values are so different that you can usually tell which kind of value is in use.
Why have BlueScale as an explicit number at all? It controls the maximum size at which overshoots are suppressed. The BlueScale cutoff and larger gets overshoots, below that overshoots are suppressed.
See also: http://www.typophile.com/node/42173 and
https://stackoverflow.com/questions/8693290/what-does-bluescale-mean-for-type-1-fonts
You are advising me to reduce the thickness of the problematic blue zone, or increase the BlueScale: but are both the same in the result?
Have I to work on the first line values?
The alignment zones are pairs of BlueValues. -18 to 0, 422 to 441, etc. They are all 20 units or less, except for the huge alignment zone from 641 to 715. Is that maybe an error? And what's up with the single-unit alignment zone from 749 to 750?
As your app does blueScale expressed as a tiny decimal instead of a ppem integer, you would actually need to reduce it. (blueScale as integer ppem and blueScale as tiny decimal have an inverse relationship.) At 0.039625, you will get overshoot at 42+ ppem. If you wanted overshoot at 33+ ppem, you could set it to 0.03096
At sufficiently small sizes, it is better to suppress overshoots than to render them as different from flat heights. So for example a capital C usually has bits that go above the cap height and below the baseline. But if it is being rendered only 16 pixels high, you probably don’t want that difference to show up.
Alignment zones are the data that specifies what heights get rounded to what other heights. So for example you might have a cap overshoot zone from the cap height to the height that the C and similar letters go above the cap height.
Without looking at the font, I can’t guess why your highest alignment zone is present at that coordinate and one unit thick. That might be catching the ascender of the f, or some such? Not quite sure what its purpose is.
https://www.dropbox.com/s/15jrywtpw4nlde0/TestPro.otf?dl=0
In any case, how can I control the hightest alignement zone? I think not watching at every font....
As for why fonts have different numbers of blue zones, there are two main reasons:
1) Some type designers may not bother adding more blue zones
2) Some fonts have more/different features. For example, when you added the superior and inferior numbers, those numbers could potentially use blue zones at their baseline and top. Depending on whether those happen to align with pre-existing zones, that might mean as many as four new blue zones.
(That's a link to the ancient PostScript Type 1 spec. This is one of many things that CFF inherits from Type 1, as far as I know.)
Your app may require you to put them in that order, or might re-order the zones automatically at export time.