You should import the T1 alignment zones after converting the outlines to TT and changing contour direction, but before you »Convert to instructions«, that way FontLab will decide which points will be aligned to the TT zones.

Jens - Thank you for your reply

So the order you recommend is

• Curves to TrueType
• Contour Direction [TT]
• Import T1 Alignment Zones
• Convert to Instructions

.

So the order you recommend is ...

Yes. If your T1 stems are set up nicely, you should also copy them over to TT stems when importing T1 alignment zones (delete the existing TT stems first, FL usually generates too many different stem values).

Have a look at
http://sites.twardoch.com/typography/font-tech/

A.

First, you must make sure that your outlines all have nodes at extremes, but I assume you already have that.

Then, make sure that the top alignment zone really covers all of your tops (from flat to round) i.e. spans over the entire overshoot. Sometimes when generating the auto zones, FontLab misses some points.

Then import the zones to the TrueType Stems/Zones dialog.

Finally, re-run the "Convert to instructions" Action for all glyphs. Only then FLS will generate the "Align to zone" TrueType hinting instructions.

Question: Where is the command "Import T1 Alignment Zones"?. And why should I use it?
If I have a PS1 file with proper alignment zones and I save it under a different name to make a TTF file, the PS alignment zones are still there, no need of 'importing' them.

Thanks in advance...

A.T.> Sometimes when generating the auto zones, FontLab misses some points.

how can this possibly be? doesn't FL have a list of the glyphs that normally refer to each alignment zone, and are not all of the points of each glyph easily accessible, and don't each of the points have a y coordinate, and can't the min and max y coordinates be simply sorted?And can't the glyph group referring to a zone define that zone by their combined mins or maxs? Am i missing something, or why is this not a software no-brainer with a 100% success rate?

Where is the command "Import T1 Alignment Zones"?

You should find that in the "TT Hinting Options" dialog, accessed via a button on the TrueType hinting Options panel cleverly labeled "..." (and whose tooltip reads "Stems Options" despite the Zones and other options within). Both the Zones and Stems sections have "Copy from Type 1" buttons.

If I have a PS1 file with proper alignment zones and I save it under a different name to make a TTF file, the PS alignment zones are still there, no need of 'importing' them.

If autohinting is enabled for generating TT fonts, the PS hinting data should be used in that process. Technically, the hinting data for stems and zones differs slightly between the formats, so translation has to occur at some stage. If you're using the above method to create TT visual instructions from PS hints, then apparently it's wise to check that all of the correct PS data is present in the TT Hinting dialog before running the conversion.

David,

FLS has a hardcoded list for alignment zone calculation, but the list does not cover *all* of lowercase or uppercase. Depending on the design, one of the glyphs FLS does not use may have an overshoot that the auto-calculated zones don't cover yet the designer might want to include these.

Adam, for future versions of FLS, it would be nice if a) the glyph list for alignment zone calculation were editable, and b) if I could define and edit separate lists for different scripts or for some other discreet subsets. For PS blue zones, FLS could combine alignment zones of different glyph lists where they overlap, but by separating the TTF alignment zone generation one could auto-create separate alignment zones for different different subsets, which is frequently useful in that whereas one might want to pop an alignment zone up a pixel for e.g. Latin caps at a particular size, one might want to pop some features of Thai at the same height down or leave them where they are.

PS. If the lists could be imported and associated with individual VFB files, like classes, so much the better, since what is appropriate for one font might not be for another.

Once you add that many variables, and per font, you might as well define alignment zones manually. You reminded me that it is less work to define required (binary) font table info right away than it is to define FLS5 FontInfo meta-information -- which, as a bonus, get me unexpected font table info as a result. :)

I think "alignments" are meant and used by the designer as guides and not parameters. It's up to an authentic auto-hinter to determine the alignment variation by looking at the glyphs that were drawn with each alignment value as a guide. This is simple. Yes, exceptions occur and must be handled, but I don't see how having an "auto-hinter" looking at some, but not all glyphs of an alignement zone, is any more useful that just taking the default alignments as the only cvt values in the TT font. . .

David: I don't see how having an "auto-hinter" looking at some, but not all glyphs of an alignement zone, is any more useful that just taking the default alignments as the only cvt values in the TT font

Working in VTT, we've often found it useful to define script-specific CVTs, not only for alignment zones but also for stems, because even when alignment zones or stem distances are very similar, we run into situations in which, at the crude pixel end of things, the best solution for e.g. the relationship of Latin x-height to ascender height isn't the best solution for the relationship of the Armenian x-height to ascender height, even though on the em the relationships may be identical. Or, elsewhere, at larger sizes, we might want the horizontals of one script to jump to two pixels at a different size than another script, typically because of the level of vertical density to be accommodated in a given height.

Quite a few people I've talked to use the FontLab autohinter as a starting place, and then apply manual tweaks to improve the results at both global and glyph levels. Being able to slice a glyph set into chunks for the autohinter to process, would enable more options in such editing.

Karsten: Once you add that many variables, and per font, you might as well define alignment zones manually.

But then you would also need to apply alignment zones manually, and I'm not even sure if FL currently allows one to have overlapping alignment zones. Let's say you want to have a Latin x-height alignment zone and an Armenian x-height alignment zone, and you want to be able to individually affect them at e.g. 10ppem, such that the Latin x-height ends up being a pixel taller at that size. That requires two things: separate definition of these alignment zones, and the ability to identify which should be applied to set an anchor for any given x-height feature.

This isn't particular to autohinting. But the discussion does suggest different views of what an autohinter is or should be. I get the impression that some people think an autohinter should be something like a PS rasteriser, trying to come up with the best rendering it can based on a minimal set of information. I prefer to think of an autohinter as a robotic replacement or assistant for a human hinter, and I want to be able to provide the autohinter with the same kind of information that I would provide to a human hinter, such as the ability to say ‘I want the x-heights of these two scripts to differentiate at x ppem size(s)’.

Question: When setting standard stem values for PS and TTF hinting, how relevant are the stems of much smaller characters like /degree/onesuperior/twosuperior ,etc. Should there be more stem values set for TTF than for PS?

John – But the discussion does suggest different views of what an autohinter is or should be.

Forget 'autohinter' for a moment. Get back to the original task (in this case: rasterizing outlines at low resolution), analyze the task, from the analysis derive a method that does the job, and express this method as a program. Neither 'auto' nor 'hinting' are left to even talk about. Only 'rasterization' as a task and a program.
This roughly summarizes my view. An 'autohinter' does not exist there. So our views differ fundamentally indeed. (You think in terms of a specific rasterization technology. I think of alternative ones.)

Ramiro,

the TrueType "stems" can also be used to control counters in FLS's TT hinting. Please have a look at my "v" and "w" examples posted in http://typophile.com/node/83661 -- you'll see two x-direction TT "stems" (X: v 393 and X: w 330). They indicate a distance between two points in a diagonal glyph, which are not really a stem.

So, in short, in FontLab's TrueType hinting, a "stem" is actually just a distance. It can be any kind of distance: between two points forming a stem, or between two points located diagonally, or between two points forming a counter. In Type 1, this does not quite work exactly that way, although to some extent, Type 1 stems can also be used to control counters.

Karsten, I've thought a lot about alternative rasterisation technologies too, and understand the merits of breaking away from hint-driven rasterisation. But hinting came into existence for a reason, and that reason is exactly the original task you describe: rasterising outlines at low resolution. There's a bit of a tendency now, because of the development costs of hinting, to view it as a problem or as something to get beyond — through increases in resolution or in new anti-aliasing techniques —, forgetting that hinting was the solution. The other things that people tend to forget is that hinting is design. In bi-level bitmap rendering, it is specific design; in the variety of antialiasing techniques now available it is, or should be, conditional design. [An analogue would be the distinction between static print design and conditional Web design.] Beat Stamm's late work at Microsoft was focused on this conditional approach, although he expresses it in terms of hinting as programming, because he's looking at it from the code side rather than the 'How to I make this shape most legible in a given condition?', which is a design question.

And it is in this context of hinting as design that I am most concerned about what I see happening in efforts to pursue new rasterisation techniques with the intent of making hinting unnecessary. Not because I like hinting or paying for hinting, but because I like design. That question, 'How do I make this shape most legible...?', is a question that I have yet to see answered for all shapes in all scripts, in the same set of conditions, without hinting playing a part. In other words, better rasterisation methods, antialiasing techniques and even current increases in screen resolution, don't seem able to produce the kind of legible results that I want in design for at least some glyphs in some writing systems. [Excepting the special case of glyph outlines fitted to a specific grid.] There remain situations in which I want to be able to tell the rasteriser that 'This stem needs to round down rather than up at this size' or that 'These two stems can be merged at this size'*. Those are design decisions, and reflect the fact that there is more to making text best legible on screen than rasterising outlines to their nearest clean fit and applying antialiasing.

So by all means come up with better ways to rasterise unhinted outlines, but don't take away the capability to make design decisions that modify or override the results. Even Apple found that there were situations, albeit rare ones under default settings, in which it was still desirable to apply hinting, even with their radical down-definition of what constitutes 'crude' conditions.

* As a good example, compare Meiryo rendering with hint designed stroke reduction under ClearType with the undesigned grey blur in Safari.

Adam: So, in short, in FontLab's TrueType hinting, a "stem" is actually just a distance. It can be any kind of distance...

Even, I suppose, what in VTT would be considered a 'grey distance', i.e. one that covers both black and white areas of the glyph. So, for instance, you could link from the outside edge of one stem to the inside edge of another, across the counter, and control that distance, rather than the counter distance itself, while anchoring the leading edges of parallel stems to the grid.

hinting is design
Second that.

"So by all means come up with better ways to rasterise unhinted outlines, but don't take away the capability to make design decisions that modify or override the results"

A bit late to be supporting this. Or as I said to Greg here years ago, "sure do cleartpye, but leave open an option for Those who can do more!"

Every idea you have now, is old and has been expressed when you had no idea.

Nothing is different about today's issues either.

Thanks.

"hinting is design"

Oh? Is sheet music composition, and dress pattern clothing design and recipe cheffery? No. Sheet music is for those who can't hear music in their heads, and dress patterns are for those who cannot feel the body in clothes, and recipe is for them without the imagination of taste. Hinting is for those who cannot see fonts without a hint.

"Thanks."

but o am i so proud of you for moving to expertise in the time you have while no others of your "group" have even approached crude media fonts and some have turned to lies and/or voodoo!

Genuine and Heartfelt Huzzzzzahs for Hudson!

"When setting standard stem values for PS and TTF hinting, Should there be more stem values set for TTF than for PS?"

For GS and CT, if the pairs of stems in e.g. a degree are exact e.g. Top and bot are 26, and left right are 30, there is no need to add them to the cvt at all, just mdrp, and they will retain identical px values, and even if different, they will be cool. If you want to make them merge to all four being identical at small sizes, the cvt the smaller pair and delta up at a few, small sizes.

Lots of values thus can be ignored if quantized to equality, and further control can be achieved by not snapping bot sides to grid, letting sub pixels do the work of the unquantized. In general I only control the alpha numerics tightly, and let the others be good via tight outlines and loose hints...