I agree. I don’t think we need a detailed book on font hinting with delta instructions. But a short explanation of how to hint stems and sidebearings for DirectWrite, along with a list of best practices regarding font-level settings that affect rendering, would be great. And it would be nice if this was on the web so we can link to it during discussions of VTT.
And, @Mike Duggan, I have to get this off my chest - where on earth was this tool eight years ago? Or sixteen? When did Microsoft get religion on the need for autohinting?
About a good test/comparison, I think picking one of the cursive/calligraphic fonts might be a better comparison test than the usual San font like Arial. If you want a large font for speed/size, have a go at wqy (http://wenq.org/wqy2/index.cgi?Home )
James, Jackson, Richard. I will look into writing something about this. For DirectWrite, there is no need to hint sidebearings, this was only done before to maintain spacing control, using hinting on sidebearings, for older rendering such as black and white, or Font smoothing. The main controls for DirectWrite, are using anchors on main heights, (Cap, x height, ascender, descender, figure height etc) using a cvt (contol value table) reference, and hinting horizontal stems, such as Cap H bar, controlled by either a Dist command or a ResDist command. Please have a study of the font that ships with VTT as a reference for hinting for DirectWrite using a cvt based approach. You can find the Font after installing VTT on your PC or Laptop, in \Document\Visual TrueType\sample\vttdemo.ttf
The Light Latin Autohinter does use a cvt reference to maintain equal heights for (Cap, x height, Ascender, Descender, Figure height etc). This is important for maintaining consistent heights both within a font and across a font family.
The Light Latin Autohinter does not use cvt's, for basic weight control on crossbars, and for contolling vertical round and straight stems. This can work well in DirectWrite.
If more strict control is needed, where exact pixel breaks need to be made consistent, for other rendering such as GDI, a cvt based approach will work better.
Richard, with newer rendering, such as DirectWrite needing less hinting controls than past rendering, such as black and white, or GDI, the new autohinting allows for a simpler instruction set, which can get us a long way. This was not something we were able to do as easily in the past. The simpler instructions, or hints are also now much easier to parse and edit.
If we have multiple weights to hint, should we put the same cvt values to all of them such that they are vertically consistent at low res? One of the issues with ttfautohint was that different weights can have different height (see this Fira bug).
yes that is a good idea. An average value will work well, if for
instance the Bold is slightly larger in x-height. If you don’t want to average
out the values, you can use inheritance to force heights to be the same across
a family, and let the true heights come back into play for higher resolutions.
For lower res, a difference of one pixel between a regular and bold weights on
screen, can be very obvious, whereas at a higher dpi, 200+ for instance, the
subtle height difference if there is any, can be described, without it looking
strange or incorrect.
But a short explanation of how to hint stems and sidebearings for DirectWrite, along with a list of best practices regarding font-level settings that affect rendering, would be great.
Or a workshop at TypeCon? Just thinking, since the deadline for proposals is Monday
@Mike Duggan So why don't you tell OSG to upgrade GDI to support y-directional antialiasing, or, if you want better compatibility, respect the GASP? WE ARE SUFFERING, ESPECIALLY ASIAN USERS. What we REALLY need is completely get rid of gridfits and make the typeface looks good on every platform.
GDI is used in less and less now, and certainly not in Browsers. If a no hinting approach is needed, its possible to set the font to use no hinting, and set the GASP Table to use full symmetic rendering at all sizes. As higher resoltion screens become the norm, hinting is less relevant, but still there are many screens, that are not what we call high resolution, and hinting is still needed there.
@Mike Duggan The largest problem is the UI font, especially CJK, are extremely distorted under GDI at UI text sizes (12-16ppem). And, as I, Zihan Chen (vczh) and Minmin Gong reported, in Windows 10, the default UI CJK typefaces' gridfit are corrupted. Yes, corrupted, under both GDI and DW. Microsoft needs to do something to fix this, to solve this, for billions (seriously) of people.
Recalculate a set of GDI-quality gridfit for Microsoft YaHei, DengXian, Microsoft JhengHei, Meiryo, Yu Mincho, Yu Gothic and Malgun Gothic using some fully-automatic process (machine-learning/AI powered?) by the Typography team/OSG/MSR. The current one is unacceptable, especially in Microsoft YaHei. (Maybe you can reference my sfdhanautohint.) All weights. All characters. Or...
Enable vertical antialiasing in GDI and disable gridfit in the fonts I mentioned. Or...
Completely remake a set of pan-CJK typefaces for Windows, just like how Apple and Adobe did.
ps. I tried to rehint Microsoft YaHei using sfdhanauothint, the result looks good to me but is still not perfect.
Recalculate a set of GDI-quality gridfit for Microsoft YaHei, DengXian, Microsoft JhengHei, Meiryo, Yu Mincho, Yu Gothic and Malgun Gothic using some fully-automatic process (machine-learning/AI powered?) by the Typography team/OSG/MSR. The current one is unacceptable, especially in Microsoft YaHei. (Maybe you can reference my sfdhanautohint.) All weights. All characters. Or...
Enable vertical antialiasing in GDI and disable gridfit in the fonts I mentioned. Or...
Completely remake a set of pan-CJK typefaces for Windows, just like how Apple and Adobe did.
ps. I tried to rehint Microsoft YaHei using sfdhanauothint, the result looks good to me but is still not perfect.
Microsoft can look at the result of running their own rasterisation test in the microsoft font validator, and try to fix the hinting problems shown in the report . While it is buggy, some of the result from the rasterisation test in the old 2003 font validator is correct. And they have an internal updated version. https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-175908319
Their internal version detects rasterisation errors under GDI and ClearType conditions also, unlike the older public 2003 binary.
@Mike Duggan @Hin-Tak Leung I tried to make a series of previews about how bad the status quo, current gridfit included in Microsoft YaHei is, compared to sfdhanautohint.. The sample text is “我能吞下玻璃而不伤身体 東国三力今書鷹酬鬱愛袋永”. You can see the serious stroke stacking in character "鷹", height inconsitency (書), and many distortions in the Bold variant.
DirectWrite under Chrome:
DirectWrite under Edge (DW with less AA levels, Ah, that's another problem: the DW in UWP requires more AA levels):
Just rearranging the characters - and adding two glyphs , 憂and 裝, to make vaguely meaningful sentence: "I can swallow glass and never hurt my body, now the 3rd/three eagle(s) from eastern country love to forcibly offer sad poctet books"
A suggestion: I think this valuable discussion is getting lost at the bottom of a thread about using the new VTT tool. I'd suggest you start a new thread so you can have an accurate title.
The hybrid branch is a set of patches and reverts to allow the current code base to use a few binary-only dll's from the 2003,binary, to fill in functionalities which was not opened and not yet re-implemented in an open manner. Currently that just means the rasterisation tests.
I think some can look at what it says about ms yahei and do some manual hint tuning.
Microsoft folks: note that you have an internal more up-to-date version of the rasterisation tests which tests GDI and ClearType conditions (which the 2003 one did not cover).
@Belleve Invis : I think you are mistaken how the rasterisation test in the microsoft font validator works, and how it is implemented. It is a fork of the windows kernel mode win32k graphic rendering engine, with additional diagnostic capabilities. As such it operates at a much lower level OS-wise, compare to *mere* Web browsers. If the windows kernel mode sub system is available for diagnostics purposes, anything else like what you are suggesting are poor choices by comparison.
It is as *real* and as low level one can get.
It is also because it is highly sensitive that Microsoft won't open-source that part of the font validator.
When I re-implement the rasterisation tests, it will also operate at a much lower level than mere Web browsers. Web browsers on open platforms depends on freetype to render fonts. So one gets diagnostics info directly from freetype.
Jackson, James, Richard, I made a start on writing a short guide. For this document, I ran the Font VTTDemo.ttf, in the Light Autohinter in VTT 6.10, and have marked up the common hinting commands that are used for the CAP H, which you can view in the main Hinting Window, VTT Talk (ctrl 5). These are the Hints added by the Light Latin Autohinter.
Follow these steps to Run the Light Latin Autohinter on the Demo font.
1. Start Visual True Type.
2. File > Open. Navigate to font file (VTTDemo.ttf) \Documents\Visual TrueType\sample\VTTDemo.ttf
3. Select Font File and Open.
4. From the Tools menu, select Autohint > Light Latin Autohint.
The enclosed PDF AutohinterLightVTT6.10.pdf, runs through some of the basic commands, (using the hinting code for the CAP H as an example) and includes more detail about each of the commands. You can view this alongside the Autohinted demo font. I have broken out the Hinting commands that get compiled, which is a simple set. Any text you see within comments /*....*/ in the VTT Talk (ctrl 5) window is not compiled.
if this is at the right level and is useful, I can expand on it, to include more characters, and the common hinting that is needed to control the basics of a Latin font. Please let me know. I can also go into more detail on different rendering modes, and settings. Even though the hinting approach is simplified, I would like to publish something at the right level that will help folks learn how to simply use the Autohinter, and make it easy to edit, and fine tune the hinting results. A full tutorial can be quite detailed, but I would like to find the right balance for beginners to those who have some experience with Hinting.
These are the setttings to best view results in VTT that match DirectWrite rendering in IE 11 or Edge on Win 10 for example.
to view the difference between hinting and no hinting, go to the main View Ctrl 1, and toggle ctrl g, (gridfit on) and ctrl g, (gridfit off). I spend a good deal of time toggling ctrl g, view , to make sure the hinted results are as expected, as well as making sure that the hinting is working as expected and not causing distortions. up/down arrow will take you through the sizes, or best also to turn on the SizeRun from the taskbar to view a range of sizes.
This is a graphic of the
basic hinting commands, that get added by the Light Latin Autohinter, apart
from the green dots. YInterpolate commands, that do not position a crossbar,
such as a H bar, are not currently added. YInterpolate commands can be added to
fine tune the results of characters such as V W v w X x, post Autohinting. If the
Light Autohinter is run on the VTTDemo.ttf font, this graphic should match
closely to the basic commands that are added, in the YDirection to control for
DirectWrite rendering.
@Mike Duggan Is it possible to provide a separate hinter or a stroke recognizer? Since scripting VTT may be difficult, a command-line hinter will be very useful.
Today I started some tests with VTT. One thing I think it would nice to have is a shortkey for 'Light Latin Autohint', and of course also a way to open several fonts and run autohinting in all of them.
Comments
I agree. I don’t think we need a detailed book on font hinting with delta instructions. But a short explanation of how to hint stems and sidebearings for DirectWrite, along with a list of best practices regarding font-level settings that affect rendering, would be great. And it would be nice if this was on the web so we can link to it during discussions of VTT.
And, @Mike Duggan, I have to get this off my chest - where on earth was this tool eight years ago? Or sixteen? When did Microsoft get religion on the need for autohinting?
The Light Latin Autohinter does use a cvt reference to maintain equal heights for (Cap, x height, Ascender, Descender, Figure height etc). This is important for maintaining consistent heights both within a font and across a font family.
The Light Latin Autohinter does not use cvt's, for basic weight control on crossbars, and for contolling vertical round and straight stems. This can work well in DirectWrite.
If more strict control is needed, where exact pixel breaks need to be made consistent, for other rendering such as GDI, a cvt based approach will work better.
Richard, with newer rendering, such as DirectWrite needing less hinting controls than past rendering, such as black and white, or GDI, the new autohinting allows for a simpler instruction set, which can get us a long way. This was not something we were able to do as easily in the past. The simpler instructions, or hints are also now much easier to parse and edit.
One of the issues with ttfautohint was that different weights can have different height (see this Fira bug).
yes that is a good idea. An average value will work well, if for instance the Bold is slightly larger in x-height. If you don’t want to average out the values, you can use inheritance to force heights to be the same across a family, and let the true heights come back into play for higher resolutions. For lower res, a difference of one pixel between a regular and bold weights on screen, can be very obvious, whereas at a higher dpi, 200+ for instance, the subtle height difference if there is any, can be described, without it looking strange or incorrect.
Or a workshop at TypeCon? Just thinking, since the deadline for proposals is Monday
http://typotalks.com/speakers/mike-duggan/
I just submitted a proposal for a workshop @ TypeCon. thanks. lets see what happens. will be a nice excuse to visit the team in Seattle
So why don't you tell OSG to upgrade GDI to support y-directional antialiasing, or, if you want better compatibility, respect the GASP? WE ARE SUFFERING, ESPECIALLY ASIAN USERS. What we REALLY need is completely get rid of gridfits and make the typeface looks good on every platform.
The largest problem is the UI font, especially CJK, are extremely distorted under GDI at UI text sizes (12-16ppem). And, as I, Zihan Chen (vczh) and Minmin Gong reported, in Windows 10, the default UI CJK typefaces' gridfit are corrupted. Yes, corrupted, under both GDI and DW.
Microsoft needs to do something to fix this, to solve this, for billions (seriously) of people.
My suggestions are:
- Recalculate a set of GDI-quality gridfit for Microsoft YaHei, DengXian, Microsoft JhengHei, Meiryo, Yu Mincho, Yu Gothic and Malgun Gothic using some fully-automatic process (machine-learning/AI powered?) by the Typography team/OSG/MSR. The current one is unacceptable, especially in Microsoft YaHei. (Maybe you can reference my sfdhanautohint.) All weights. All characters. Or...
- Enable vertical antialiasing in GDI and disable gridfit in the fonts I mentioned. Or...
- Completely remake a set of pan-CJK typefaces for Windows, just like how Apple and Adobe did.
ps. I tried to rehint Microsoft YaHei using sfdhanauothint, the result looks good to me but is still not perfect.https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-175908319
Their internal version detects rasterisation errors under GDI and ClearType conditions also, unlike the older public 2003 binary.
@Hin-Tak Leung
I tried to make a series of previews about how bad the status quo, current gridfit included in Microsoft YaHei is, compared to sfdhanautohint.. The sample text is “我能吞下玻璃而不伤身体 東国三力今書鷹酬鬱愛袋永”. You can see the serious stroke stacking in character "鷹", height inconsitency (書), and many distortions in the Bold variant.
DirectWrite under Chrome:
DirectWrite under Edge (DW with less AA levels, Ah, that's another problem: the DW in UWP requires more AA levels):
GDI under Chrome:
Where do you get the 2nd clause from? For those who don't read Chinese, the first clause means " I can swallow glass and not hurt my body..."
Just rearranging the characters - and adding two glyphs , 憂and 裝, to make vaguely meaningful sentence: "I can swallow glass and never hurt my body, now the 3rd/three eagle(s) from eastern country love to forcibly offer sad poctet books"
https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/win32.hybrid/win32.hybrid-bin-2016_02_08.zip/download
The hybrid branch is a set of patches and reverts to allow the current code base to use a few binary-only dll's from the 2003,binary, to fill in functionalities which was not opened and not yet re-implemented in an open manner. Currently that just means the rasterisation tests.
I think some can look at what it says about ms yahei and do some manual hint tuning.
Microsoft folks: note that you have an internal more up-to-date version of the rasterisation tests which tests GDI and ClearType conditions (which the 2003 one did not cover).
I do not think validators work. Testing rasterization should use real environments. Web browsers are good choices.
It is as *real* and as low level one can get.
It is also because it is highly sensitive that Microsoft won't open-source that part of the font validator.
When I re-implement the rasterisation tests, it will also operate at a much lower level than mere Web browsers. Web browsers on open platforms depends on freetype to render fonts. So one gets diagnostics info directly from freetype.
The enclosed PDF AutohinterLightVTT6.10.pdf, runs through some of the basic commands, (using the hinting code for the CAP H as an example) and includes more detail about each of the commands. You can view this alongside the Autohinted demo font. I have broken out the Hinting commands that get compiled, which is a simple set. Any text you see within comments /*....*/ in the VTT Talk (ctrl 5) window is not compiled.
if this is at the right level and is useful, I can expand on it, to include more characters, and the common hinting that is needed to control the basics of a Latin font. Please let me know. I can also go into more detail on different rendering modes, and settings. Even though the hinting approach is simplified, I would like to publish something at the right level that will help folks learn how to simply use the Autohinter, and make it easy to edit, and fine tune the hinting results. A full tutorial can be quite detailed, but I would like to find the right balance for beginners to those who have some experience with Hinting.
These are the setttings to best view results in VTT that match DirectWrite rendering in IE 11 or Edge on Win 10 for example.
ctrl D, or Display/Options.
cheers
Mike
Opinion later...
This is a graphic of the basic hinting commands, that get added by the Light Latin Autohinter, apart from the green dots. YInterpolate commands, that do not position a crossbar, such as a H bar, are not currently added. YInterpolate commands can be added to fine tune the results of characters such as V W v w X x, post Autohinting. If the Light Autohinter is run on the VTTDemo.ttf font, this graphic should match closely to the basic commands that are added, in the YDirection to control for DirectWrite rendering.
Is it possible to provide a separate hinter or a stroke recognizer? Since scripting VTT may be difficult, a command-line hinter will be very useful.