BlueValues and BlueScale in Private Dictionary

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

Comments

  • Thomas PhinneyThomas Phinney Posts: 2,732
    edited February 2019
    What the error means is that, in a PostScript or CFF font, you have a Blue Zone (alignment zone) that is too large for the BlueScale.

    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
  • I use Linux, so I'm using FontForge. I'm working on a .otf.
    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?
  • mauro sacchettomauro sacchetto Posts: 353
    edited February 2019
    I find there values:

    Have I to work on the first line values?
  • Well, if you reduce the thickness of a blue zone, anything that sticks out will no longer be getting overshoot suppression at all.

    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
  • You ask me
    And what's up with the single-unit alignment zone from 749 to 750?
    Well, how can I realize, empirically speaking, what does it happen?

  • Thomas PhinneyThomas Phinney Posts: 2,732
    edited February 2019
    Alignment zones are one of several kinds of information in the font that are used to force the rendering of the glyph (in pixels or dots) to be more consistent, when there are not enough pixels/dots to accurately represent the outlines.

    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.
  • mauro sacchettomauro sacchetto Posts: 353
    edited February 2019
    You can see here the .otf:
    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....
  • Now we are into FontForge-specific questions; I will defer to the FontForge documentation (https://fontforge.github.io/en-US/documentation/), or other FontForge users. 
  • mauro sacchettomauro sacchetto Posts: 353
    edited February 2019
    I tried to read some articles / guides... but IMHO but there is a lack of clarity and the FF guide provides absolutely generic information In some fonts are indicated 4 pairs of BlueValues, in other cases 5 or 6. Where can I find out what exactly they refer to and why the information is so different? My unique certainty is that the first pair is the baseline overshoot position and the baseline and that the pairs can indicate up to 14 numbers...
  • Yes, that's right. The numbers are the vertical (Y axis) coordinates. FontForge can display the blue zones in a glyph window with View > Show > Blue Values. Then you can see what the zones apply to.

    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.
  • But is there a mandatory order to place the various zones?
  • Thomas PhinneyThomas Phinney Posts: 2,732
    edited February 2019
    That is a question for the specs and/or your app. I think the spec covers the order and other things about pp. 36-37. https://www-cdf.fnal.gov/offline/PostScript/T1_SPEC.PDF

    (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.
Sign In or Register to comment.