Is necessary to import manually the stems before running TTFAutohint?
Ramiro Espinoza
Posts: 839
I would like to know if the old step of manually importing PS1 stems into the Fontlab's TTF windows make sense when the font is going to be hinted with TTFAutohint. Or the software take care of hese things?
Thanks in advance. R.
Thanks in advance. R.
Tagged:
0
Comments
-
Hi Ramino,
Unless you use the -p parameter, my guess is that they are ignored (But can't confirm that). To be 100% sure, ask Werner Lemberg (wl@gnu.org)0 -
By no means do I understand how TTFAH works but I spent a day experimenting with it and couldn't get stems or blues to change the output. Contour-direction, on the other hand...0
-
This is what I asked Werner Lemberg:
"Could you please tell us what is the best way to prepare FL files
for TTFAutohint? When converting a PS1 font to TTF, should we
import some PS1 hinting (plus stems and blue zones) or all this data
is going to be overwritten by TTFAutohint? Or just converting the
contours to TTF splines and changing the direction is enough?"
And this is what Werner Lemberg answered:
"Converting to TTF is enough since ttfautohint removes all hints. Note
that option -p makes only sense for fonts which use hinting to shift
and scale subglyphs, like the old `mingli' font.
I'm going to further improve the fine-tuning possibilities of
ttfautohint. However, the idea is that ttfautohint provides the basic
hinting which gets corrected afterwards if necessary (for example,
adding some delta instructions). Unfortunately, there don't exist
font editors AFAIK which support such post-hinting, but I think this
will soon come."0 -
Seriously guys, have you seen one good example of a font family that performs well together, which has been autohinted with TTFautohint?
In my opinion you can easy get a much better result by doing some semi auto hinting inside FontLab, and those hints you can edit afterwards with full control.0 -
Yep, lots of examples.
Vernon Adams has done extensive testing and examination of the results during the last year, comparing Manual Hinting, TTFAutohitnt, and the DTL Autohinter. The latest comparative is available at http://www.dutchtypelibrary.nl/ under "Latest DTL News: Autohinters Compared.
One example that I think that renders pretty good is Domine
http://www.google.com/webfonts/specimen/Domine
Look at it at small sizes under WinXp/Chrome, and compare to other fonts in the same environment. (WinXP-Chrome is possibly the most challenging combination of Browser/OS)
BTW: TTFautohints keeps improving in each new release, as Werner is still working on it. Feel free to submit your suggestions and provide him with your feedback. That will also help him to keep improving it.
0 -
I saw that examination before, the only problem with those all single screenshots is that we can’t see when the x-height goes from one pixel to the next in a whole family, which is essential if you have more than one style.
It’s also important to see the typeface in a lot of sizes to see how it changes, how the details in the letters are following the size changes.
Let’s say you make one word in bold or italic inside of a paragraph. You surely want that bold or italic to behave just like the regular and change x-height, stem widths etc at the same time so the whole paragraph is balanced. Is this possible to control when using TTFautohint?
Even thought it’s only two styles with a very thin bold style ( four or more with a strong bold would have been better ), I’ll have a look at Domine and may report my findings
Thanks for pointing that to me because screenshots made by one person is really nothing worth when speaking of hinting, examinations must be done with real live fonts.1 -
I may turn your world upside down here, Pablo, but I just now made a three minutes quickie-test on Win XP, IE with ClearType. Grabbed a text, copied into a html-document and activated Domine.
Just a few comments:
– The dieresis on ä and ö becomes a macron on the bold.
- All the s have become 8 on both regular and bold.
– The lowercase bold a surely need to have some more air inside of it.
And this is only on one size view...
No offence, but this is not a good example People still use these old machines, and it’s for those we hint
-------
0 -
I may turn your world upside down here, Pablo... No offence, but this is not a good example
No problem Göran. I know it's far for ideal.... But for XP/Chrome combo (the worst possible environment) I think it's good enough. Have you compared it to other webfonts in the same settings? People still use these old machines, and it’s for those we hint 0 -
Regular XP/Chrome @ 60, 24 and 16px (default line-height) - Click to enlarge
Bold XP/Chrome @ 60, 24 and 16px (default line-height) - Click to enlarge
0 -
...examinations must be done with real live fonts
Domine 24/16 @ XP/Firefox:
Compare to Sentinel SmartScreen at everydaytype.com, CSS live-edited to the same size and background color (24/16px, also XP/Firefox) - Click to enlarge
0 -
Let’s say you make one word in bold or italic inside of a paragraph. You surely want that bold or italic to behave just like the regular and change x-height, stem widths etc at the same time so the whole paragraph is balanced. Is this possible to control when using TTFautohint?
Yep, there are a few parameters to control the x-height rounding up or down (You may want to use -x and -X) They can also be controlled for specific size ranges.
Call "ttfautohint -h" for a list of all parameters available.
0 -
I get the feeling that your worst case scenario is not the same worst case scenario I have when looking at fonts on old PC-machines
Anyway, this screen shot throwing doesn’t really show anything new. There are more parameters.0 -
Seriously speaking in all the test I've done fonts hinted with TTFAutohint looked much better (in XP/Explorer and Firefox) than fonts with their PS hints properly converted to instructions. Of course it can not be compared with manual TTF hinting but it works quite well as basic, affordable hinting. It is AUTO hinting, nobody expect it to be perfect.1
-
ttfautohint is indeed meant to provide *basic* hinting, to be adjusted afterwards if necessary (I believe that some font editors will have support for that in the not too distant future).
Göran's critique is justified, and I plan to further improve my little baby (currently, progress is quite slow since I'm busy especially with FreeType). However, since ttfautohint applies no hinting along the x direction, complete control over the stem width is not possible with this tool.
BTW, I've just added a TODO entry w.r.t. font family harmonizing. To a certain extent this is already possible using the -X option, but maybe a finer control is possible (this is something still to investigate).
Please bear in mind that ttfautohint hasn't reached version 1.0 for good reasons. It's amazing that so many people are using the tool already...1 -
I recently noticed that a font I was hinting had a problem with the Q. The bottom loop of the letter was filling excessively at certain sizes. When I looked at the PS auto hinting I found that the horizontal PS hint for that part of the letter which was present in the O was missing. When I added it the problem went away. This leads me to conclude that the PS hints can clearly be valuable to getting better results from TTFA.
The obvious next step would be to do an A/B test with and without across a range of different styles to see what the interactions are. However I won't have time for several weeks.
I also want to note two other things which have not been mentioned here but which may help people who want to try or to use TTFA.
• The size of the type in the UPM matters a great deal. TTFA will give you better and worse results with a change as small as 1% in some cases. Just taking a finished print design and running it through TTFA is not an ideal use of the technology. And yet you see this a lot - the Domine example discussed above is just one of many examples of making this kind of mistake.
What is the right thing to do instead? If you are going to hint Domine properly with TTFA you should do an analysis of how to best alter it to work on low rez screens. It might be that all you have to do is scale it. It might be that you have to make the design coarser like toy might for use at small sizes in print. Perhaps both. Maybe a larger X height. Maybe an altered Cap height. And so on. Looking at the difference between David J Ross Turnip for print and Turnip for screen in the RE version shows some of the optimizations that are often appropriate.
• Establishing one orthodox approach to using TTFA is a mistake. One of the great things about TTFA is that you can vary settings. This is established. But the less obvious thing is that TTFA is insanely fast. This means you can test your design over and over in an iterative manner to optimize it with TTFA. The real value to my way of thinking in TTFA is that you can get such rapid feed back and you can genuinely optimize your font to the technology.
• Making a screen oriented version is the right thing to do. Where conventional TT hinting is designed to take a print design and contort it to work at small PPEMs TTFA lets you make a separate optimized design. I would contend that this is smarter for a really wide variety of reasons. Designing one version for all media is a bad habit that is historically speaking pretty new. We aught to abandon it. TTFA encourages us to do the right thing not just for Windows but for Macs and mobile devices too.
• Not all designs are suitable for TTFA now. When I tried to use TTFA hinting for Pinyon Script I found that It distorted the design far too much. On the other hand Conventional hinting would have as well. I had to fall back on the technique Google invented which is to add this to the PREP table.
PUSHW_1
511
SCANCTRL
PUSHB_1
4
SCANTYPE
This activates anti aliasing.
It may be that as TTFA is improved that it is able to handle finer lines better. I think it is quite possible and I know Werner has thought about how to do this.
• Because not all styles ( especially thin ones but also very heavy ones ) are not hinted well by TTFA it may mean that really large families whose primary stayle variation is weight have to be hinted using the old methods. But a) TTFA may get better at this if it is funded further and b) bringing a huge range of weights to the web may not be what is needed. Thinking about other kinds of style variation will get better and more meaningful results for the web.
• The best thing about TTFA is the way it lets more of the flavor of the font through than other methods do. The very reason most people get interested in one font vs another is differences in feeling or voice. Thus the whole point of having a web font is for it to look and feel different from the fonts on peoples devices already. In letting more flavor through TTFA does the type designer a huge favor.1 -
Just taking a finished print design and running it through TTFA is not an ideal use of the technology. And yet you see this a lot - the Domine example discussed above is just one of many examples of making this kind of mistake.
What makes you think that Domine is a print-font? Wrong assumption Eben...The size of the type in the UPM matters a great deal. TTFA will give you better and worse results with a change as small as 1% in some cases
Agree on the importance of the UPM.
I tested a lot of variations for Domine, and ended up choosing a 1000 units UPM and a BBox height of 1140. So that it gives you a 19 pixels grid of 60 units each, when set at 16px on screen.
This way the auto hinter does not need to "guess" if it may round-up, or it may round-down the x-height... as there is no need to round in the first place (when set at 16px, since that was the target size).
This also prevents the "Fussiness under the baseline on mac" sindrome: http://typedrawers.com/discussion/106/fussiness-under-the-baseline
0 -
...and Turnip for screen in the RE version...
Here you can see both set at 16px on XP/Chrome:
Turnip looks much better, but it's also wider and a bit bolder (and better designed, of course).
But as for the hinting quality of ttf-autohint vs manual hinting, there is not much difference.
Both have a 9 pixels x-height, +4px for the Ascenders, +3px for the Cap, -3 for the Descender, etc...
In Domine the diacritics does not overlap even if you use a 1em line-height in the CSS. In Turnip I haven't tested. In H&FJ Sentinel Smart Screen diacritics do overlap if you set a 1em line-height, at least the last time I tested (it may been fixed by now, or not... don't know).
By the way... keep in mind that we are comparing a font made by a beginner self-teached like me, to some of the best top-quality webfonts available in the industry, like those of Webtype and H&FJ... Of course Domine will not be nearly as good as those fonts are, but I'm quite happy with my results so far. And this discussions are great to keep learning.0 -
I think this is a great discussion, I'm glad it's happening. But if I can pick nits here:
"– The dieresis on ä and ö becomes a macron on the bold."
This isn't something that hinting can control in Cleartype (as it's in the X direction), you'd have to adjust the outline, which isn't bad as long as you're targeting a specific size(s).
Also, Google invented enabling dropout control? I remember setting that before there was a Google.
0 -
It looks to me like the bold in that sample is synthetic, in other words, created by doubling or smearing the plain weight along the x axis.0
-
@mark Really? I assume you mean in Pablo's 2 screenshots?
I don't think so, because if you look at the terminals of the strokes in the lower case "e" and "c", in the bold, it's clearly cut at an angle. I think you'd get more of a horizontal edge if you'd smeared in the X direction.0 -
No, I mean in Göran's screen shot, with the dieresis becoming a macron.0
-
Question: Have anyone of you guys who thinks the TTFautohint tool is great, actually hinted a font? Or are you just sort believing that what you see on your personal screen with your setting is either good or bad and take it from there?
@jasonc
In this case I think it’s actually the TTFautohint tool that creates this problem. Without any hinting at all, I don’t think the dieresis would become a macron like this.0 -
@Werner
I really appreciate your effort, don’t misunderstand me (I guess some people do) but I’ve heard too many times that this tool beats manual TT-hinting by some people who appaerently don’t know what they are talking about.
Q: Are you having someone to work with on this tool that has knowledge of TrueType hinting with all its parameters?0 -
Goram, nobody says that this (or any other) tool beats manual hinting... of course that's not the case. All we says is that the results are good-enough to avoid spending our time doing it manually. And hopefully, in the near future the ttfautohints result will also be editable, to make the needed corrections.
Have anyone of you guys who thinks the TTFautohint tool is great, actually hinted a font?
I attended the Hinting session on ATypI 2011 Reykjavík where Mike Duggan and Si Daniels from Microsoft explained the process, using VTT (Visual TrueType tool).
http://www.atypi.org/past-conferences/2011-reykjavik/programme/activity?a=34
And believe me, it's not something I want to spend my time doing... If other people want do it, it's Oka... but not for me, thanks
@Mark, Jason:
I don't know... maybe, or maybe as Goran suggested we are getting different results from our screens. That's another possibility.
Here is how I see Domine Bold as small as 12px @ XP Chrome
And here is how I see Domine Bold as small as 12px @ XP Firefox
0 -
Here's what I mean: Compare the first and second row here. These character images where taken from Göran's screen shot.
Each glyph is exactly one pixel wider in the bold than in the regular. Also notice that the pixel color pattern on the left and right side of each glyph is exactly the same between the regular and bold. It looks exactly like the bold was created by making a copy of the regular and shifting it one pixel to the right.
I don't believe the bold in this instance was derived from the true bold font, but faked from the regular weight. Why this would happen I don't know, but it's probably more likely to be a failure of the browser to display the correct font (maybe because of something in the CSS), and not the fault of the hinting.3 -
Yep, Mark seems to be right. Göran's screenshot looks like a fake-bold... Or maybe it's just an Internet Explorer Issue?
Thanks Mark... you got some fine-tunnend eyes!0 -
No it’s the true bold: pixels in these small sizes don’t have so many places to go. It’s a very limited pixel grid, and that’s why hinting is needed for these environments.
The glyphs on Reg and Bold are also very similar, so then it becomes like this. Why should it become any different when the glyphs are almost identical but just a little thicker?
This is how hinting works on the “old machines”, it’s either one... or two pixels.
Why don’t everybody just get a Mac so we don’t have these problems ;-)0 -
I can understand them being similar, but these pixel patterns are identical, and every character is exactly one pixel wider. What are the odds? Faulty style linking triggering fake bold is a more reasonable explanation here. It fits the evidence perfectly. Is it even possible for hinting to make one font render exactly like another font, but pixel doubled on the x axis? And just in one browser/OS combo?0
-
In case my earlier image wasn't clear enough…
Row 1: The plain weight from Göran's screen shot
Row 2: Same image, shifted one pixel to the right
Row 3: Row 1 and 2 overlaid in Photoshop (layer mode, Linear Burn)
Row 4: The "bold" weight from Göran's screen shot
There are some slight differences here, but that could be because Linear Burn doesn't perfectly simulate whatever XP is doing, or maybe differences in Gamma.0 -
On the opposite, I think the odds for them to be different would be higher. The patterns are almost identical because they come from almost the same outlines. One is just thicker and wants to jump up to two pixel and become a bold. The other option would be that the bold jumps down and become the regular.
Anyway, I’m leaving this discussion now – I have no intention in convincing anyone, it seems you all prefer to think that fonts very easily render good on older OS/computers, which in a way is understandable since it makes life easier
Here’s some screen shots directly from Google fonts, WinXP. Do you also think they use a faux bold?
1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports