Setting BlueValues suggested by FontLab

mauro sacchettomauro sacchetto Posts: 353
edited April 2019 in Font Technology
In order to identify the BlueValues ​​etc, I read that the AFDKO stemHist tool is able to identify a series of values ​​to work with. However, I have some difficulties installing it due to incompatibility with Python versions.
Waiting to resolve this problem, it seems to me that FontLab suggests or imposes values ​​in a more or less automatic way. In the meantime I would like to see what values ​​set, but generally working with FontForge from Linux I know very little about FontLab, of which I installed the trial version in the Windows partition.
I could not find the tool or window from which to do this. In FontInfo I only see the data with the original settings. How can I perform this reset operation with the values ​​suggested by FontLab?
Moreover: can I work on a otf for this?
Thank you
«1

Comments

  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    What exatly do you need? BlueValues (alignment zones) and StandardStems (vertical and horizontal widths of stems, for which stemHist is used) are different hinting options.

    BlueValues:

    Standard Stems:

    You can click on the button with ruby in both windows and FL will try to calculate values automatically

  • I mean both, but in Font Info window
    I don't find the voices you are speaking about...

  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    I use FL5 while you FL6.

    I don't know exactly how it works in FL6, but I think that you should look somewhere there to find necessary values.

  • Finally I found. However, the result is not so good.
    Rendering in Windows (both with Adobe Acrobat Reader and Edge) show some flaws.
    The most obvious here is the glyph of the "z", not aligned and lower than the others. What can it depend on?

  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    You can open a glyph and try to hint it manually or try reassign global settings e.g. bluezones + blueshift + bluescale.
  • but, if I can't currently have the data provided by AFDKO stemHint, how can I recalculate the bluezone settings etc?
  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    stemHist script shows only stem widths histogram aka most popular widths in your font, nothing more


    this information can be used for StandardStems values.

    I think you should read OpenType Adobe specs document to get better understanding of postscript hinting and its params.
  • mauro sacchettomauro sacchetto Posts: 353
    edited April 2019
    I saw the pages you reported to me. However, the theory does not always produce happy results, because of my limited skills.
    I have modified some values ​​and in fact now the defects are very reduced. The glyphs rest (almost) all correctly on the same baseline.
    However, there are some residual defects, related to specific glyphs and to certain resolutions on Windows both with Adobe Acrobat Reader (I have already tried to change the hinting settings, but without result) and with Microsoft Edge, while on Linux you always see well.
    For example with a display below 100% and at large resolutions the glyph of the letter "v" is badly seen, while those of "m" and "n" have curved lines that are too thin and appear taller than the other glyphs. The "x" glyph very appears very small. I enclose two screenshots from Adobe Acrobat Reader, the first with a 92% zoom, the second with a 197% zoom.
    In case, I can post a link to the .otf, if anyone can take a look at the values ​​I set. Thank you

    Screenhot 92%

    Screenshot 197%

  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    Looks like you set global hinting values but hadn't used glyph level hints (autohint all glyphs) or your params were chosen incorrectly.
  • mauro sacchettomauro sacchetto Posts: 353
    edited April 2019
    I changed some parameters slightly,
    then I deleted the previous hintings and I redid the autohinting.
    However, little has changed.
    These are the settings:



    and this the otf: https://www.dropbox.com/s/lak6dslz3zxbbtp/TestPro.sfd?dl=0
    Is it too much if I ask for a verification of the parameters?
    This way only can I understand the actual errors I continue to make :(
    Thanx a lot!
  • FontLab VI version 6.1.4 was released some hours ago and brings improvements on this area (besides several others and some new features). Find more here.
  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    Your font has a large variety of contours with a large difference zones and stems.
    And also you have a lot of redundant nodes in contours in my opinion.

    But changing bluezones and bluefuzz=5 gave me this result:

    This is only an example and not final values for you. 
    I strongly recommend you spend the evening reading the opentype specs, pay attention to Flex hints. 
  • mauro sacchettomauro sacchetto Posts: 353
    edited April 2019

    I've updated FL, but the values ​​that "guess" don't solve my problems.
    I will certainly follow your indication to also deepen the theory.
    In any case it is more convenient which I set at 5 bluefuzz?
    Finally: to fix my troubles is it enough to operate on BlueValues? Or should I touch other types of value in parallel?
  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    In any case it is more convenient which I set at 5 bluefuzz?
    Finally: to fix my troubles is it enough to operate on BlueValues? Or should I touch other types of value in parallel?
    BlueFuzz value expands BlueZones in both directions up and down. It can help when glyph heights jump.
    Font alignment depends on bluevalues + bluescale + blueshift + bluefuzz
    Font width depends on standardstems + glyph level hints

    https://glyphsapp.com/tutorials/hinting-postscript-autohinting
    https://glyphsapp.com/tutorials/hinting-manual-postscript-hinting

    Read at least these tutorials to understand how parameter values interact with each other and affect rendering. Then look for the values that best fit your font in practice.

  • Thomas PhinneyThomas Phinney Posts: 2,731
    The stem widths really have only a little to do with blue values. Blue values are for overshoot zones: that is the DIFFERENCE between the standard height and the overshoot height. The standard stems do not, and cannot, directly tell you what the overshoots are.

    Bluefuzz is overused, I think. At least half of fonts can have bluefuzz set to zero.

    If you want to share your font file, I would be curious to see what is going wrong with the "z"
  • FontLab VI did not export some replacement hints and zones correctly, which may have influenced you results. The just-published 6.1.4 fixed many problems in that regard! 
  • Yes, I updated FL. My last trials were carried out precisely with the latest version. But, as I wrote before, this didn't completely solve my problems
  • Thomas PhinneyThomas Phinney Posts: 2,731
    There are definitely things wrong with your blue zones and/or blue shift.

    Why you have such a massive blue shift, I don't know. Is there some reason for that? I would say that most fonts are best served by blue shift of zero.

    I suggest sharing your font with Fontlab support at https://support.fontlab.com so people can actually look at your glyph outlines relative to the blue zones. The blue zone values by themselves don’t tell us much.
  • mauro sacchettomauro sacchetto Posts: 353
    edited April 2019
    I started from scratch, that is from the original glyphs, to which I had probably applied too often cleaning and various hintings. I did not touch the automatic settings produced by FontForge and now the visualization also on Windows is (finally) correct.
    These are the settings:



    I don't understand the meaning of the last couple of values, which are the same ones (750 750).
    BlueShift is still set to 6. I will try to set this parameter to 0 and review everything, because, even though I proceed by trial and error, I start to understand something :)

  • Thomas PhinneyThomas Phinney Posts: 2,731
    Some of those numbers are not great. There are WAY too many stem snap values, too close together. That will just make for uneven rendering at small sizes on screen—at least, in rendering environments that use that data from the font. Apple will be fine since they ignore all your hinting anyway.  ;)
  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    Yeap.
    [40, 44, 49] = 44
    [54, 62] = 58
    [34, 42] = 38
    [65, 66, 67, 70, 72] = 69
    [81, 82] = 81
    Otherwise, the render may be confused by your values.

    750 is ascender height of b and d
    Your fl liga height is 743 you can try to set (743, 750) instead of (750, 750)
  • Thomas PhinneyThomas Phinney Posts: 2,731
    Viktor's suggestions seem reasonable.

    Note that there is not a single set of right answers to this question of stem snap values. In general, one’s choices could and perhaps should be influenced by the frequency (and possibly relative importance) of the stems in question. For example, within one set of stem values, if one particular value is much more common or more important than the others, you might either use it, or weight it appropriately in the average.
  • I tried to recalculate the data "by hand" by checking the baseline, the x-Height, the Cap-Height etc. The result is still imperfect.
    If on Mac and Linux there is no problem, on Windows, due to the way in which it make rendering, with a magnification of less than or greater than 100%, some glyphs have a bad output: always the usual ones, that is m, n or w.
    However, I noticed that if I completely delete glyph hinting, even on Windows you can see the pdf perfectly in all resolutions. Is it a suicidal solution?
  • Thomas PhinneyThomas Phinney Posts: 2,731
    Having no hinting will often yield reasonable results at high resolutions and reasonable sizes. BUT....
    • it will not work so well at more modest resolutions/sizes (lower ppem sizes)
    • it will do especially badly in older non ClearType Windows rendering systems. Such rendering can sometimes be invoked even on versions of Windows that support ClearType.
    You can always try other systems if doing it the usual way is too difficult. TTFautohint for example generally produces fairly decent results. FontLab VI has TTFautohint built in, as an option/alternative....
  • Kent LewKent Lew Posts: 905
    TTFautohint still needs reasonable Blue zones and StemSnap values to start with, doesn’t it?
    In my limited experience, fewer values are usually better than bad values. And IMO, no hinting is often better than bad hinting.
  • Viktor RubenkoViktor Rubenko Posts: 119
    edited April 2019
    Kent Lew said:
    TTFautohint still needs reasonable Blue zones and StemSnap values to start with, doesn’t it?
    Yes, it does. But it try to determine values automatically and you can influence them a bit through settings.
  • mauro sacchettomauro sacchetto Posts: 353
    edited April 2019
    Analyzing the glyphs and values ​​of other fonts, I think I understood the mechanism for attributing Blue Values.
    I do not understand instead the criteria of assignment of StemSnapH and StemSnapV, nor how many values ​​should be inserted. Any suggestions?
    And should be the StdHV and StdVW the 
    most statistically frequent values?
    Thank you very much

Sign In or Register to comment.