rendering differences between python scripting interface and the older scripting interface

[HinTak]

• Provide a general summary of the issue in the Title above.
• Before you open an issue, please check if a similar issue already exists or has been closed before.

I have written two versions of the same thing -
#3085 (comment)
to convert Noto CJK/Source CJK for TexLive's use.

The encoding vector is identical as expected. Though visually for practically purposes undistinguishable, there are rendering differences at the glyph level for contours against
AddExtrema() and Simplify().

Important

Mark with [x] to select. Leave as [ ] to unselect.

When reporting a bug/issue:

• [*] Screenshot
• [*] The FontForge version and the operating system you're using
• [*] The behavior you expect to see, and the actual behavior
• [*] Steps to reproduce the behavior
• (optional) Possible solution/fix/workaround

I have screemshots of both outcomes, as well as the original, for a particular glyph I look at in detail. These I should attach shortly. It looks as if the python default of AddExtrema is "do nothing", versus the other side's of breaking a the horizonal and vertical extreme ends.

fontforge-20161012-6.fc26.x86_64 from fedora.

It is not exactly clear from the documentation what's the python side default of AddExtrema is - it sounds as it should do "sensible" things, but not.

du :
29028 python-generated
29388 native-script-generated
28324 native-script-generated-without-AddExtrema

file size overall wise, the python generated result is between the native-script-generated one and it without AddExtrema. The individual subfonts can go in both directions - I just looked at the smallest subfont (1 glyph) with a large difference in size, and found that the python generated version isn't adding the extrema; there could be other differences from Simplify() also. (screenshots to follow)

I have no idea which is correct - but the underlying C code looks the same ( in fontforge/scripting.c and fontforge/python.c, and one can look at them side-by-side), so it is a bit curious; also at least the documentation on the native side looks better documented than the python side, for this API, at least. And the defaults, etc should agree, and if not, documented.

When you open an issue for a change/improvement/feature request:

• A description of the problem you're trying to solve, including why you think this is a problem
• If the feature changes current behavior, reasons why your solution is better
• (optional) Possible solution/fix/workaround

[HinTak]

side by side, note where the control points are for the contour at the top right corner.

The original.

[HinTak]

As I mentioned earlier (repeating some info):

du :
29028 python-generated
29388 native-script-generated
28324 native-script-generated-without-AddExtrema

file size overall wise, the python generated result is between the native-script-generated one and it without AddExtrema.

So the python AddExtrema() default behavior is definitely not "do nothing"; it just seems to do a bit less than the legacy script version's AddExtrema() default without arguments.

Some of the size differences might be due to the "2" passed to Simplfy() - but I doubt a "2" is parsed and converted differently in the two cases.