GSHint.horizontal reports wrong (inverted) values

I’m adding some manual TrueType hints via scripting, but I noticed that the GSHint.horizontal flag is inverted. If I set it to True, it adds a vertical (:arrow_up_down:) hint, and if I set it to False it adds a horizontal (↔) hint.

You can also see the same problem by using the GUI to add a vertical (:arrow_up_down:) hint, like this:

…and then running the following macro:

for h in Layer.hints:

…which results in the vertical hint being reported as horizontal:

<GSHint 0x11166ee70> h TTStem [0, 11] + [1, 11] = [-] True

This issue was raised in another thread a couple years ago, but it seems like the issue was misunderstood and still exists in 3.1.2 and 3.2.

The nomenclature is a bit confusing, I know. The direction means the stem that is being hinten. For PS hints (that use the same flag) it is better visible as the gray bar is following the direction of the horizontal flag.

I think you’re overlooking that TT hint directions are defined in the opposite way in the handbook. According to the handbook, horizontal hints are on the x-axis and are shown when the double arrow is toggled this way (↔). Vertical hints are on the y-axis and are shown when the double arrow is toggled this way (:arrow_up_down:).

But when GSHint.horizontal is set to True, the TT hint becomes a vertical hint on the y-axis, and is only visible when the double arrow is toggled to vertical (:arrow_up_down:). It should become a horizontal hint when the property is set to True, but it doesn’t.

Since PS hint directions and TT hint directions are defined inversely to each other, maybe there should be two properties like ttHorizontal and psVertical which both result in x-axis hints when set to True? Then the API would behave correctly, the handbook wouldn’t need to be rewritten, and existing scripts wouldn’t immediately break.

Then the handbook needs to be updated. @FlorianPircher

Perhaps it would be less ambiguous to use “x” and “y” when referring to hints, and “horizontal” and “vertical” only when referring to features of letter shapes such as strokes/stems/serifs/etc? This is generally the terminology I’ve seen used by other hinting tools such as VTT and YGT.

That property was introduced more that 10 years ago and there was no reason to change it, since. And it only shows up in the python API.

I meant for the terminology in the handbook and other documentation like Rainer’s hinting tutorials.