--- Begin Message ---
Plaintext file. Be sure your txt interpreter can read UTF-8, the UTF-8 BOM and
the Microsoft newlines.
/*
While the current increase of computing power would allow for better
algorithms to handle B/W auto-hinting, it becomes moot at the same
time because the increase of today's screen resolution even for the
cheapest displays makes hinting unnecessary, more or less.
*/
Seeing the community think like this is cringe. This only delays the development
of ttfautohint even further, even though bilevel optimized hinting is of course
a very important feature. On my laptop display, (1366Ã768, 101Ã101dpi, which
is
about 96dpi) bilevel-optimized hinting is the best hinting. And it remains so
even in displays of five fourths times the dpi (120dpi) and six fourths times
the dpi (144dpi). Even in double the dpi (192dpi) bilevel optimized hinting is
clearly the sharpest text rendering. For hinting to be "unnecessary" you would
have to approach Infinity dpi exponentially, that is, work on 384dpi, 768dpi,
1536dpi displays, etc. . And that would be really expensive. All because of the
mindset that blurry text is ever so slightly, but not really, better on higher
resolutions than on lower resolutions. That's desirable for a commercial company
like Microsoft (it can get away with selling systems that default to incorrect
gamma anti-aliasing, which looks awful regardless of resolution), but certainly
undesirable for free software. I suggest ttfautohint developers to immediately
think of ways to achieve bilevel-optimized hinting.
/*
// ======
//
// Width control: In proportional fonts, horizontal hinting may change
// widths.
Not with FreeType's auto-hinter that gets used by ttfautohint! The
widths are always identical to the original ones.
*/
Uh, what? Isn't it a redundant statement, as ttfautohint currently uses no
horizontal hinting? The reason I mentioned this, is that the FontForge
autohinter, which appears to hint both horizontally and vertically, changes
widths, which of course completely breaks fonts whose design is dependent on
spacing.
/*
It's not clear to me why you are concentrating so much on hinting at
such small sizes. As the old MS core fonts (Times, Arial, Palatino)
have demonstrated, it is an incredible amount of work to do this
correctly. Note also that MS abandoned B/W hinting for characters
that have been added later to the core fonts. This means that today
only a small fraction of the glyphs in those fonts actually do work
correctly with B/W hinting.
*/
The reason hinting the Microsoft fonts was painful is because that was the only
job the hinters could find. On the other hand, the true hinting of some free
fonts is made by the free software community. The Microsoft fonts are completely
irrelevant to this as they are of no use towards developing free fonts. The
removal of horizontal hinting to later glyphs is irrelevant as well: I think
they did this to speed up the initial development of the character set, while
retaining full hinting for many characters (this includes the WGL4 set, which is
what most of the Latin, Greek and Cyrillic content consists of). It is not
impressive at all, and a closer look can reveal imperfections of hinting in all
fonts, whether it be stem weights diverging at larger sizes, or an imperfect
letterform for a particular size.
/*
For such small sizes, a cheaper, probably better, and definitely much
easier solution is to create embedded bitmaps and/or pixmaps, the
latter using a low number of gray values. A few years ago I visited
the famous Morisawa company in Japan, which produces probably the best
Japanese fonts. In one department there were a bunch of people who
created such pixmaps of CJK characters. In other words, this *is*
used, at least for CJK glyphs, and I don't see why this can't be used
for non-CJK scripts, too.
*/
I don't think most environments support this. Microsoft Calibri has embed
bitmaps, but they don't appear to be used, ever, at all. Instead, GDI uses its
broken hinting. I've heard Microsoft Windows has to detect for several Japanese
characters in the font before using embed bitmaps.
/*
You would be able to use such hinted fonts for screen-display only,
for example, to display menus. If you want to have something similar
to WYSIWYG, such hints are completely useless.
*/
Uh. Isn't that true for pretty much all fully hinted fonts?
"You would be able to use Arial for screen-display only,
for example, to display menus." "If you want to have something similar
to WYSIWYG, such hints are completely useless."
"You would be able to use Courier New for screen-display only,
for example, to display menus." "If you want to have something similar
to WYSIWYG, such hints are completely useless."
"You would be able to use Times New Roman for screen-display only,
for example, to display menus." "If you want to have something similar
to WYSIWYG, such hints are completely useless."
Horizontal hinting is fundamentally dependent on the layout being reflowable.
Don't let that distract the developers from implementing horizontal hinting.
/*
// Unify the blue zones for ascenders and descenders if possible by the
// font design. Because some fonts have them the same, or within 1
// unit, etc. it makes for consistent hinting.
This I don't understand. Please elaborate and give an example.
*/
DMCA Sans Serif:
x-height: 1004
ascender-height: 1413
descender-height: -410
difference between x-height and ascender-height: -409
However, in ttfautohint, the difference between x-height and ascender-height is
independent of the descender height. So they end up with different values!
/*
// Width delta: The monospaced width becomes a cvt rounded to an
// integer, and the user can choose to delta it. By default, this
// feature is not used.
No idea what you are talking about. What feature do you mean?
*/
If the width cvt is delta'd, the width changes for every glyph in that size.
/*
// Those are hinted horizontally. But watch out. Keep in mind that
// they are at a different angle, so with calculations (relative to the
// horizontal and vertical stem weights) the points that terminate the
// diagonal stems need to be at a specific horizontal distance. It
// should be consistent with the horizontal and vertical stem weights â
// especially when those are 1 pixel, where an unhinted stem stands
// out. You could have various diagonal cvts that would determine the
// horizontal distances for diagonal stems at various angles.
You mean precomputed values?
*/
So, for example the vertical stem weight goes
1, 1, 1, 2, 2, 2, 3, 3, 3, 3, 3, 3, 4, 4, 4
and the horizontal stem weight goes
1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, 5, 5, 5
so, for example, a diagonal stem weight might go
1, 1, 1, 2, 2, 2, 4, 4, 4, 5, 5, 5, 6, 6, 6
and it is used at the ends of diagonal stems.
/*
// ======
//
// First of all, handling diagonal stems on the S/s characters. I've
// actually figured out a way to do it: https://i.imgur.com/2S3prC2.png
// . It involves there being an interpolate instruction from the top
// of the top and bottom stems to a control point of the top of the
// diagonal stem, and so with the bottoms of stems, and this
// interpolation automatically makes the middle stem hinted to the
// proper weight.
Looks good. Could you transform this image to some (mathematically
based) algorithm? Or reformulate it using bytecode instructions?
*/
The interpolate instruction is an interpolation. Suppose there are points
a, b, c, having coordinates in one dimension. After hinting, a and b move to
locations A and B. So, when c is interpolated between a and b, its coordinate
C becomes (((c-a)/(b-a))*(B-A))+A. I don't think you should really use this
raw equation, as it leads to rounding errors.
--- End Message ---
