stemHist finds different stem lists on Windows than on Mac.

[readroberts]

No description provided.

[frankrolf]

It’s even better than that. Lists for the same source UFO differ across Macs.

[miguelsousa]

@frankrolf do you have any test fonts to reproduce this?

[frankrolf]

font.ufo.zip
The attached UFO is the one I use for an exercise explaining the use of stemhist.
It’s common that the bottom values for p and q are not found on my machine, while they are found on students’ computers.
This is the example command:
stemhist -a -g a-z,A-Z,zero-nine font.ufo

In general, the resulting report files slightly differ from machine to machine.

[miguelsousa]

@frankrolf in #552 I made changes that stabilize the sort order, and remove duplicate entries, but none of those changes fix the inconsistencies across environments you've reported, because the bug is really in autohintexe.

stemhist basically just reformats the data provided by the reports (-ra and -rs options) issued by autohintexe. For example, when I run stemhist -q -g a-z,A-Z,zero-nine -d font.ufo (the -d option writes a file named rawdata.txt), I get different results in Mac and Win for glyphs b and H.

Mac

HStem b top 55.000000 bottom 0.000000
VStem b right 159.000000 left 72.000000
VStem b right 159.000000 left 72.000000
VStem b right 159.000000 left 72.000000

HStem H top 407.000000 bottom 342.000000
VStem H right 177.000000 left 84.000000
VStem H right 177.000000 left 84.000000
VStem H right 620.000000 left 526.000000
VStem H right 620.000000 left 526.000000

Win

HStem b top 738.000000 bottom 0.000000  <-- extra line
HStem b top 55.000000 bottom 0.000000
VStem b right 159.000000 left 72.000000
VStem b right 159.000000 left 72.000000
VStem b right 159.000000 left 72.000000

HStem H top 719.000000 bottom 0.000000  <-- extra line
HStem H top 719.000000 bottom 0.000000  <-- extra line
HStem H top 407.000000 bottom 342.000000
VStem H right 177.000000 left 84.000000
VStem H right 177.000000 left 84.000000
VStem H right 620.000000 left 526.000000
VStem H right 620.000000 left 526.000000

It seems that this problem may be mostly happening with sans-serif glyphs. My guess is that it has something to do with the creation of ghost hints; these don't get generated if the edge of a vertical stem is not within an alignment zone.
The stemhist test data uses Source Serif, and the results are consistent across platforms.

As you know, autohint is getting replaced by psautohint. The latter doesn't have the report options yet, but there's this open issue to address it https://github.com/adobe-type-tools/psautohint/issues/71

/cc @khaledhosny

[miguelsousa]

@khaledhosny I've built autohintexe from the psautohint repository, and I'm getting the same results as above. Shall I open a new issue, or do you want to track it as part of https://github.com/adobe-type-tools/psautohint/issues/71?

[khaledhosny]

Tracking in adobe-type-tools/psautohint#71 is fine.

[khaledhosny]

Can you try with the autohintexe binary from https://ci.appveyor.com/project/adobe-type-tools/psautohint/build/1.0.627 (check the artifacts of the relevant build)?

[miguelsousa]

@khaledhosny with that build the Win output is now the same as the Mac. But I think the extra lines in the Win output were correct.

[khaledhosny]

The changes I did in this branch are fixing undefined behavior issues related to bit shifting and integer overflow, so I don’t know what output is correct, it is just now that the compiled code does not rely on any undefined behavior (which with some compilers and aggressive optimizations, can result in code being optimized away in unexpected ways). We should now debug this and see why these extra lines are missing.

[miguelsousa]

@khaledhosny is this fixed?

[khaledhosny]

I still need to find out whether the old Windows output was the correct one, but the inconsistency between platforms should be fixed.

[miguelsousa]

OK. The reason why I think the extra lines in the Windows output were correct is because HStem _ top 738.000000 entries are generated for other lowercase glyphs with ascenders, like l and h, for example.

[khaledhosny]

I’m rather lost here. So far, this seems to be caused by PruneHVals() pruning one hint val in the b glyphs that it does not prune on the d glyph, though there top and bottom points look rather identical. Specifically, this condition is true the second time it gets executed in the b glyph but not in the d glyph. But I’m having hard time deciphering what this code is trying to do.

[miguelsousa]

@khaledhosny can you add a unit test for PruneHVals() ? That may help to confirm that the bug is really in there.

[khaledhosny]

We don’t currently have the infrastructure to add unit tests for functions deep inside the C library like this one.

[miguelsousa]

This issue has been eluding you for weeks. Is that not a strong enough motivation to get C unit testing off the ground?

[khaledhosny]

It is not that I don’t like having unit tests, it is that I’m not sure it is as easy as it sounds. The code uses global variables a lot and most of the active state; the parsed paths, the hints, and what not are all in global variables, so I’m not sure how this all will be possible to cleanly test single functions. Based on experience, it is going to be a multi-week small project if not more.

[miguelsousa]

Got it, thanks. I'll work with the latest version and log any issues I find. Is version 1.9.0 stable?

[khaledhosny]

1.9.0b2 should be stable, if you can give it a try and if everything is OK I can cut a final release.

[miguelsousa]

Added a test case using the font and command provided and the CI is green. Closing as fixed.