Proposal: Control instruction set for ttfautohint on ideographs

Belleve Invis

Currently my ideographic hinter, sfdhantuaohint, heavily relies on FontForge’s file format, and it is an ideograph-only solution (which means that it cannot hint latin scripts).
Therefore I am purposing a instruction set for ttfautohint’s control file. 

1. General Rounding: Round a point’s y-position.

[font‑idx] <glyph-id> yround <points>

2. Size-specific positioning : Place a point to specified position (in pixels) at specified size.

[font‑idx] <glyph-id> ypos <points> <coordinate - in pixels> @ <size>

3. Alignment: Move a point to align with a repositioned point’s new position (at specified size). This may be size-specific (used in stroke positioning).

[font‑idx] <glyph-id> yalign <points> -> <pointID - rp>
[font‑idx] <glyph-id> yalign <points> -> <pointID - rp> delta <distance - in pixels> @ <size>

4. Interpolation: Interpolate a point using IP[] mechanism.

[font‑idx] <glyph-id> yip <rp1> <- <point> -> <rp2>

The application order is General Rounding → Size-specific positioning → Size-specific Alignments → General Alignments → Interpolation.

cc. @Werner Lemberg 

Werner Lemberg

Thanks for the proposal.  However, this looks quite theoretical to me.  Can you please give a detailed example that shows what you want to achieve?

Belleve Invis

@Werner Lemberg
You should know that, hinting ideographs requires stroke merging at small sizes. For example, the 島 part in the image above has a stroke (z9-z10-z100-z97) merged to the stroke below it.

The control instruction of this character at 12ppem should be like this:

15<-88->82 // Size-independent Interpolationsuni6417 ypos 3,45 10 @12 // Position z3,z45 to 10px above baseline
uni6417 ypos 43 9 @12
uni6417 ypos 80 8 @12
uni6417 ypos 93 7 @12
uni6417 ypos 100 5 @12
uni6417 ypos 11 5 @12
uni6417 ypos 15 3 @12
uni6417 ypos 82 1 @12
uni6417 ypos 66,29 -1 @12
uni6417 yalign 79->80 96->43 99->93 10->100 14->11 42->15 91->82 67->66 30->29 1 @12 // stem widths
uni6417 yalign 4->3 86->82 // Size-independent alignments, no rounding
uni6417 yip 15<-92->82 15<-84->82 

As a new consideration, maybe applying the control instructions in the written order is better than a fixed built-in order.

Werner Lemberg

It's still not clear what you want to do.  Those control instructions are to be applied after ttfautohint's auto-hinting, or instead?

And please repost the second image with applied hints, but this time disabling the original outline, only showing the hinted one, which are hardly visible otherwise.

Belleve Invis

@Werner Lemberg
Instead. Hinting ideographs is completely different from hinting letters. However, considering the semantics of the purposed instructions, I think they can be used for the “after” scenario (before IUP[y] is executed).

For hinted outline of 搗 at 12ppem:


Note that two strokes are merged (z11-z12:z14-z13 and z100-z97:z10-z9)

Werner Lemberg

Thanks for the new image.  However, if you had disabled the check mark in the `Q F Fore' line, I would be able to see the green, hinted outline *much* better 

I'm not sure that `instead' is a sensible solution; it would mean that you have to correct the rendering for every PPEM value separately, thus making the hinting data really huge.

Have you done some rough checks to find out how much data you get for the `after' scenario?

Finally, note that FreeType has support for multiple auto-hinters.  I always try to synchronize the FreeType code in ttfautohint as much as possible with FreeType itself (it helps a lot if you are the maintainer of both packages ), so it wouldn't be too hard to add a second auto-hinter module to ttfautohint also.

Belleve Invis

@Werner Lemberg
First, images:


Second, The size of final TTF with 27000 glyphs is about 24MB, a typical size of fully-hinted CJK font. I do not think switching to “after” will reduce the instruction size: the major part of the gridfits are DELTAPs to arrange points under every “interested” sizes (in most cases, 12-35 ppem).

Finally, I do not think that FreeType currently have a hinter able to deal with stroke merging. sfdhanautohint’s merging strategy is figured out using an AI with many empirical strategies. Porting it into ttfautohint may be harder than expected, so providing an interface (using control files) and let other programs (like sfdhanautohint) to provide the result directly is a better solution.

Werner Lemberg

The images are much better now, thanks!

You can better evaluate whether integration of your baby into ttfautohint is easily done or not, so I trust your verdict.

Regarding the instruction set: Could you provide a simple but complete example for a single CJK glyph of a well-known CJK font?  I would like to have a text file with your proposed control instruction file together with a single-glyph font that uses your generated bytecode so that I can single-step by myself.

Note that I can't promise any time frame for a closer look, unfortunately.

Belleve Invis

@Werner Lemberg

Here it is: http://7xpe0v.com1.z0.glb.clouddn.com/sg-test.ttf

The corresponded “control file” is https://gist.github.com/be5invis/60624c1aa94b078d447a9cf4dc434222