Setting BlueValues suggested by FontLab
mauro sacchetto
Posts: 353
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?
Moreover: can I work on a otf for this?
Thank you
0
Comments
-
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
0 -
I mean both, but in Font Info window
I don't find the voices you are speaking about...
0 -
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.
0 -
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?
0 -
You can open a glyph and try to hint it manually or try reassign global settings e.g. bluezones + blueshift + bluescale.0
-
but, if I can't currently have the data provided by AFDKO stemHint, how can I recalculate the bluezone settings etc?0
-
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.1 -
-
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%
0 -
Looks like you set global hinting values but hadn't used glyph level hints (autohint all glyphs) or your params were chosen incorrectly.0
-
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!0 -
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.
0 -
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.0 -
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?0
-
BlueFuzz value expands BlueZones in both directions up and down. It can help when glyph heights jump.mauro sacchetto said: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?
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.
0 -
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"0 -
0
-
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!0
-
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 problems0
-
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.0 -
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
0 -
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.
2 -
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)1 -
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.0 -
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?0
-
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.
0 -
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.0
-
Yes, it does. But it try to determine values automatically and you can influence them a bit through settings.Kent Lew said:TTFautohint still needs reasonable Blue zones and StemSnap values to start with, doesn’t it?1 -
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
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports