Next release

[ctrlcctrlv]

I think we should start scheduling the next release. A number of important bug fixes have gone in. I want to give us enough time to get #3915 in, though. How about a January 2020 release? Let's aim for Jan 1 2020? Or do we want to say Dec 15 as most people take vacation for Christmas and New Year's?

[jtanx]

Sounds ok to me, although scheduling an exact date around that time will always be a bit tricky because of holidays.

In case anyone's wondering, I'm (trying to) focus on some personal projects which I've been procrastinating for far too long, so don't expect any major changes from me for a bit.

[frank-trampe]

I'd prefer the earlier December date. Otherwise, people might say that we didn't get them anything for Christmas.

@ctrlcctrlv, you're driving most of the non-bug-fix development and a lot of the bug-fix development. Particularly with me and @jtanx tied up and thus not embarking on major efforts right now, it seems appropriate to me that you make and manage the punchlist for this release if you're willing.

[skef]

So ... suppose that the stroke system were to be entirely replaced. Any change that substantial would require a major review and probably some field testing. Would that be viable for this release at all? (That is, counterfactually supposing the code were available today, could it make such a release?) If so, how much lead time would be needed?

[ctrlcctrlv]

I'd say if it was ready by November 1 we could make it into the December 15 release, considering I'd test it a lot to find any issues.

[skef]

@ctrlcctrlv I might well make that date, so that could work between us. Not everyone may be happy with leaving it between us, however. There are some tricky side issues, like SVG importation and weight changes, that depend on that code. And some GUI and python interface modifications.

[frank-trampe]

It's my understanding that the initial implementation of the new stroking would be able to exist alongside the old one. If so, it's not really a problem if it doesn't tick all the boxes initially. In the long run, it makes a lot of sense to prefer the Inkscape-shared code for anything imported from SVG, so that might be sellable as a bug-fix rather than a breaking change.

[ctrlcctrlv]

@frank-trampe Sorry—we're not in constant contact, as much my fault as yours, perhaps we should have a call some day, or an IRC chat? I've only emailed you a few times outside of our public Git discussions. We actually gave up on the Inkscape-based implementation, now @skef has his own implementation which is actually even better than Inkscape's, give it a try I'd say, the latest branch name is, I believe, skef:stroke2. It's so cool, any convex polygon can be used as the nib!

[frank-trampe]

Oh, what?! I did miss that somehow. I'd love to learn a bit more about it.

I just looked at the branch, and there is clearly a tremendous amount of code to review. Are there tests? I'm confident that you two can deliver something that is categorically better (as in correct whenever at odds with the old implementation). The question is to how to deal with the cases in which the results deviate but the old results are not clearly wrong such that they are part of somebody's workflow. Once we know that, we can ask the right questions on the mailing list.

[skef]

Are there tests?

A deep question. Before I start to answer let me emphasize that the code isn't finished and there are a number of potential issues I won't go into here, both within the code and beyond it (the latter mostly falling under splineoverlap.c).

At the most mundane level the automated stroking tests attempt to process all the StrokeTests.sfd glyphs with a circle and a number of polygons. But it doesn't check the output.

StrokeTests.sfd has a number of shapes that are challenging for either circular or square nibs. There's also a collection of issues that have additional shapes that have been problematic. All that stuff works now by visual inspection. I still have to add an accuracy tunable (for both curve tracing and "Simplify") but that shouldn't be a substantial change.

There's only one implementation, so circles/ellipses and squares/rectangles are just shapes. Given that those work the additional challenge is making combinations of lines and curve work. (Or more specifically, different combinations of vertex-drawn segments and curve-drawn segments need to work.) I have a collection of nibs that I would argue cover the special cases and those exposed a bunch of problems but I fixed them.

There's a problem with how ChangeWeight uses stroking I haven't tracked down yet that causes counter-clockwise areas to disappear, but that's likely a very simple calling convention I just haven't looked at yet. But unfortunately the outline point positions from my code won't be the same, so you can't just sfddiff the old and the new. If there were an area-based diff tool or something else for this kind of case that would be handy.

So in terms of future correctness testing, one means is to enhance StrokeTests.sfd with more paths and background outlines and a python script to call the stroke code with the appropriate parameters for each glyph. Then the file could be inspected visually. With a bunch of complex and corner cases that would go a long way.

[skef]

I still haven't implemented joins and caps beyond those formed by the nib shape itself. Just replacing GW's system would be easy given that he punted on any options outside of circles and ellipses (and the latter are misleadingly labeled). I want to mostly generalize the options, which has led down a long road with many unfruitful side trips. But I think I have a reasonable handle on things now.

[skef]

It's hard for me to say how much of a risk the splineoverlap.c issues pose because I plan to do most of the cusp removal "myself" using a different mechanism. But there may be corner cases that my system can't deal with and Remove Overlap barfs on. I don't yet have a good sense of the scope of such corner cases or how to arrive at that scope.

Of course, there are plenty of cases the current system barfs on.

My code allows a user to short-circuit the algorithm and clean the glyph up themselves, so there won't be any more "not all fragments are joined" tossing up of the hands. That's a cold comfort if you're attempting to change the weight of 500 glyphs, but change-weight is typically called with "sub-cusp" parameters. (That is, the curvature of the circular nib used to decrease the size of a concave spline-set is typically higher than any point on that splineset.)

[skef]

I guess I should also note that I'm fine with delaying this and may not make that date anyway. Another option would be to schedule a later release specific or mostly specific to the stroke system. However, it would be a shame for it to slip too long for lack of reviewing resources.

[skef]

Once the stroke code is feature complete and in reasonable shape I'll presumably be fixing whatever bugs are found in it, but may have cycles for other bugs. Can we/should we/how would we identify the best candidates? (Presumably higher-impact, not too large, etc.)

[jtanx]

Identifying issues we think are important sounds good to me.

As for the method, you could add a label, make a project and add them to it, make a milestone and tag them to it, or just tag them here; I'm not too fussed which method gets used tbh, as long as we generally follow one for this cycle.

NB: I assume (but cannot currently test) that FF is broken on macOS Catalina with the removal of the Carbon APIs

[skef]

@ctrlcctrlv What's on your plate has changed a bit since you filed this. What's your current thinking about #3915?

[ctrlcctrlv]

"changed a bit" is certainly the understatement of the century :-)

We've emailed a bit about it. Let me know if you'd like to help with the Python part, it's appreciated, as you're really the expert when it comes to the Python API, and it seems like a bunch of new APIs need to be added to get #3915 in.

[skef]

@ctrlcctrlv worked around his short term image-reference requirement and I'm not actively working on #3915 either. I don't personally think it should be closed but there also isn't a big hurry.

The new Expand Stroke implementation is in master and I'm pretty close to getting arcs joins implemented. I still need to document around #4073 but that shouldn't be hard. We don't have a solution for #4049 and #4050; I may or may not look at the existing algorithm in the near future. In any case I don't think a release in the next two weeks is sensible but if necessary it could probably happen pretty soon after that. (I don't currently see why that would be necessary, but it could be desirable.)

In terms of other work for the next release I think it would be valuable to make some more progress on the recent F-UFO bugs involving anchor points. I could probably push through some fixes and implementations if someone more knowledgeable could nail down the correct behavior. (That would probably be @frank-trampe.) I understand that the research time may outweigh the implementation time so this might just not happen.

We also need to figure out where to put the Expand Stroke document on the website. As everyone probably already knows I favor switching back to the HTML docs, perhaps after a preliminary reorganization of the top-level. HTML/CSS work is the sort of thing you can get non-programmer volunteer help with. Is there any chance of that?

[ctrlcctrlv]

I think there are still situations where #3915 is very useful, but I worked around it for my situation by writing #4074. I don't think it hurts to leave it open. I recently contributed a feature to kovidgoyal/kitty, (kovidgoyal/kitty#2248,) and while doing so, I noticed that some of its PR's are marked as "Draft". Is there any chance we could do that?

[skef]

I've made a project for the next release (and added this issue, so the link is above). I use the bug triage template and added a bunch of potential bugs, most still untriaged.

My list is based on going back through last March or so and picking out those I thought we more likely to get some attention. Because I've gone back through the list multiple times in the past I don't think there are many earlier low-hanging fruit.

I'll say once again that I think it would be valuable to sort out some of the UFO problems that have cropped up. I am willing to work on them if and when someone can specify what FontForge should do in these cases.

[ctrlcctrlv]

@skef I don't want to annoy you, but am also really curious about something.

Why, for example #4109, or #3958, but not #3569 (created March 23 2019)? Is #3569 just hopeless? (Heaven forbid! It is a perennial crash I run into.)

Also, if we're calling dibs on the bugs you chose, I'd like to be given the chance to fix #3983. It is a bug I have personally experienced many times, and having just come off of #4115, I think I know how to fix it.

[skef]

All those bugs are just ideas about what might make sense for the next release; the who/when questions are entirely open. You can presumably call dibs by assigning it to yourself (seems like a good convention for these, if maybe a little sketchy more generally). So by all means: grab #3983.

As for the other question -- well, first off, #4109 is "my fault" and the new stroke code should go out as clean as possible. (Lord knows new users will find problems.) And anyway it's easy. I also added #4049, which is known to be hard and is an existing bug, but the lack of a solution continues to bother me so I'll probably take another look now that I have more bug stamina again.

#3958 is a (presumably) repeatable seg fault in a remove path. It's also likely to be easy.

I don't know whether #3569 is hopeless, but it's in the spiro code which I've only barely looked at. It's also known to be at least difficult. So, basically: who is likely to look at it enough to fix it for the upcoming release? I couldn't think of anyone.

[jtanx]

Something not to forget before cutting is to pull in new translations from crowdin.

[skef]

There is one subtle, rarely occurring problem I've run into with rectangular nibs in the current Expand Stroke implementation. It shows up as an assert when I expand all of LibertinusSerif-Regular but probably as a sub-standard output contour in the release code. It's a weird corner case I haven't been able to track down yet; something having to do with the very specific geometry of a particular splineset. It's not a blocker -- users will inevitably run into worse problems we haven't identified yet, so we might as well get it out there so that can happen.

Beyond that, though, with the merge of #4144 I'm done with this phase of the project as far as I currently know. I've been plugging away at other bugs for a week or two and there are nine remaining in the release project I made, but most of those are optional.

I still think it would be good to work through some of these UFO issues, and figure out contrib. I'll try to look into the mechanics of the latter. But maybe it's time to start thinking about a specific release date target.

[ctrlcctrlv]

I plan to implement #703 as the first contrib script @skef. Thus, #4143. That is, if you give me the honor. :-P

I think part of the reason we have no contrib scripts is we have no contrib scripts. (Incredibly meta.) So having one will open a door, I think. And #703 is as valid an issue to implement via a contrib script as any.

[skef]

Remember that the argument over the narrow understanding of "contrib" versus the wider potential for scripted content wasn't settled but was leaning towards a high bar for the former. Still, I don't see why a solution to #703 wouldn't meet that bar.

[skef]

I've shifted various issues on and off the Q1 2020 release project as part of their ongoing evaluation^†. Two of the remaining open bugs either look resolved (#4104) or have a potential fix that will either make it or won't (#4044).

The third is the contrib conventions bug. I see this as waiting on some or all of #4147. It isn't yet clear how to best manage contributions and I think some of those advanced features should be part of the conversation. However, I don't favor holding up the release for that. It's been a while since the last one and the master has many improvements and bug fixes. We can always do the following release after a shorter delay if we like.

In short there's nothing "on my end" holding up a release other than various PRs that need sorting through. @jtanx has added #4182 to the project but that's likely close to being mergable. I suggest we get serious about a proposed schedule.

^† Obviously I and others have gone on a cleanup spree of closing old issues without fixes. I would argue we've been quite conservative, in that the issues closed that way were genuinely unlikely to have any further value or impact. The many past suggestions and blue-sky ideas remain. What shouldn't get lost among those issues are the many recent fixes, which by my quick count number around 40 in the last month (if you include some of the still-open PRs). That's not counting all the Expand Stroke-related bugs closed earlier, the many bugs found and fixed in other related systems (Simplify, Add Extrema, one or two in Remove Overlap) as part of that project, and a number of other bugs fixed earlier in the cycle.

[skef]

Seems like we're very close. I approved the version change PR conditional on picking a new date. Build infrastructure changes to #4194 look fine to me; I'm not qualified to judge the other stuff.

I'd like to get #4204 in if we can get it reviewed. @frank-trampe you should add something about the Glyph-level Import/Export options to the change log. #4207 and #4205 also seem like they can easily make it. (#4191 is a draft - ignore it.) The rest of your text looks fine to me (assuming @ctrlcctrlv's stuff is added).

#4141 has been languishing without review. I'll take a look and see if I can ramp up enough on it.

It's likely this release will go by less noticed due to world events but that would be a silly reason to hold off. Seems like we can merge the close-to-ready PRs and pull the trigger as soon as we feel like and @jtanx has the time.

[jtanx]

Ok, let's try now for the 14th of March, let's make it a hard cutoff this time, no last minute changes.

[milotype]

I just did some more croatian translation on crowdin ... one day before cutoff time ;-)
If possible, please add it in the next release. Thank you!

[jtanx]

Thanks @milotype - done

[jtanx]

@frank-trampe everything's merged, you can tag if you like.

[jtanx]

Actually just a sec, need #4220.

[frank-trampe]

I just got back. Give me a moment to finish release notes.

[frank-trampe]

Check one last time to make sure I did not miss anything big.

• FontForge now has much improved stroke expansion functionality. The main change is that it actually works most of the time. New features include support for arbitrary convex nibs and the miter-clip and arc join styles from SVG 2. All functionality is accessible from the Python and native APIs. (By @skef.)
• Remove overlap handles certain important edge cases better. (By @skef and @frank-trampe.)
• The Python API now has a function called genericGlyphChange that matches the "Change Glyph" command in the GUI. See Add glyph-level genericGlyphChange (same as UI "Change Glyph ...") #4133 for more details. (By @skef.)
• The Python API now has functions for getting Unicode script and for interrogating glyph boundaries. (By @ctrlcctrlv.)
• One can now use text flags (rather than just numerical flags) when opening a font file via the Python API. (By @skef.)
• UFO import now outputs the note field properly. (By @skef.)
• SVG import is much more robust. (By @skef.)
• We have dropped most gnulib and autotools logic in favor of CMake, which dramatically simplifies the build system and just as dramatically improves build time. (By @jtanx.)
• As part of the switch to CMake, per the deprecation of Python 2, and per the lack of objections to the proposal on the mailing list, we have dropped support for building FontForge with Python 2 support. The non-build-system Python 2 code remains, but it is neither tested nor maintained nor supported and is likely to follow a trajectory of decay and then removal.
• Documentation is now rendered in Sphinx, which makes maintenance and improvement easier. (By @jtanx.)
• Translations now happen on crowdin, which makes contributions easier. (By @jtanx.)
• We got such a contribution for Croatian. (By @milotype.)
• The user can now move and close tabs in the character view. (By @ctrlcctrlv.)
• The metrics view now allows for entry of negative kerning values and runs a bit more smoothly.
• There is now a warning when a user is about to discard an unsaved script. (By @ctrlcctrlv.)
• We fixed bugs all over, as always, with particular attention given to the metrics view, Python, Spiro, and high-resolution displays.

[jtanx]

I'm out for a couple of hours, coverity picked up a couple which might be worth fixing.

Changelog (for my parts at least) looks ok

[jtanx]

I fixed the trivial ones in #4221.

[skef]

@frank-trampe Looks good. If I were sending this out I would probably delete the open flags entry -- people who need that will find it in the docs when they do.

[frank-trampe]

I don't think that it's any less significant than other stuff on the list. And, unlike a bugfix, somebody benefits from it only when he knows about it.

[skef]

That's fine -- I'm probably just wistful about #4003 .

[frank-trampe]

Oh! I did miss that. I have fixed it now.

• FontForge now has much improved stroke expansion functionality. The main change is that it actually works most of the time. New features include support for arbitrary convex nibs and the miter-clip and arc join styles from SVG 2. All functionality is accessible from the Python and native APIs. (By @skef.)
• Remove overlap handles certain important edge cases better. (By @skef and @frank-trampe.)
• The Python API now has a function called genericGlyphChange that matches the "Change Glyph" command in the GUI. See Add glyph-level genericGlyphChange (same as UI "Change Glyph ...") #4133 for more details. (By @skef.)
• The Python API now has functions for getting Unicode script and for interrogating glyph boundaries. (By @ctrlcctrlv.)
• One can now use text flags (rather than just numerical flags) when opening a font file via the Python API. (By @skef.)
• UFO import now outputs the note field properly. (By @skef.)
• SVG import is much more robust. (By @skef.)
• We have dropped most gnulib and autotools logic in favor of CMake, which dramatically simplifies the build system and just as dramatically improves build time. (By @jtanx.)
• As part of the switch to CMake, per the deprecation of Python 2, and per the lack of objections to the proposal on the mailing list, we have dropped support for building FontForge with Python 2 support. The non-build-system Python 2 code remains, but it is neither tested nor maintained nor supported and is likely to follow a trajectory of decay and then removal.
• Documentation is now rendered in Sphinx, which makes maintenance and improvement easier. (By @jtanx.)
• Translations now happen on crowdin, which makes contributions easier. (By @jtanx.)
• We got such a contribution for Croatian. (By @milotype.)
• Character view point coloring is more consistent, and preview fills support transparency. (By @skef.)
• The user can now move and close tabs in the character view. (By @ctrlcctrlv.)
• The metrics view now allows for entry of negative kerning values and runs a bit more smoothly.
• There is now a warning when a user is about to discard an unsaved script. (By @ctrlcctrlv.)
• We fixed bugs all over, as always, with particular attention given to the metrics view, Python, Spiro, and high-resolution displays.

[skef]

Oh - I had assumed that just didn't meet the bar. Teach me to be unassertive I guess.

To me that looks like an excellent summary

[frank-trampe]

@jtanx, I have tagged the release with pre-release status. Let me know when you have packages up, and I'll send a note to the mailing list.

[jtanx]

Done

[frank-trampe]

Wow. Ninja does make the builds go fast, I guess.

[frank-trampe]

@milotype, I need your name in order to give credit in the e-mailed release notes.

[jtanx]

https://github.com/fontforge/fontforge/blob/master/po/hr.po#L7

[frank-trampe]

Very clever, @jtanx.

[frank-trampe]

I have sent the release announcement to the mailing list. I suppose that we can close the issue unless somebody thinks of other outstanding tasks.

[jtanx]

Hmm, I don't see the announcement on the mailing list

[frank-trampe]

Sourceforge makes me angry sometimes. I'll work on this tomorrow.

[ctrlcctrlv]

I will have a permanent address again soon. I will tweet tomorrow about the new release. I'll hopefully be back to work next week, or in two weeks at latest. Hopefully coronavirus doesn't fuck up that plan, sucks that the whole world goes to shit when my own world went to shit, but what can you do?

[milotype]

Clever, indeed ... thank you @jtanx! Cheers, Milo

…

Frank Trampe ***@***.***> hat am 14. März 2020 05:58 geschrieben: Very clever, @jtanx (https://github.com/jtanx). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#3933 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AKNCQYQBJHVHKTE2TXEZHY3RHMFJDANCNFSM4IX4I4BQ).

[skef]

@ctrlcctrlv Hope you're hanging in there. Do make some kind of twitter announcement, however brief, when you get a chance.

[ctrlcctrlv]

@skef Sorry for the delay.