What's your pen hardware ? I reckon this does affect smoothing somewhat (in particular higher refresh rates may increase jitter and maybe the curved mode is actually less good at higher pen input rates).

I guess you've done a round of different solution you could try. If you have found one in particular that feels nice for some reason I'm interested to know which one.

After looking at what you listed, I have a few notes and a few ideas, but nothing definitive I want to do.

• What is done in lorien seems similar to the second mode for path modelling (curved in the path modelling options) where we use the positions from the current event + 2-3 before and interpolate a curve. One thing that's also added in lorien here is to lessen the number of events if they're too close to one another. That's a basic way to compress a little filesizes and maybe jitter a little bit.

• There are a few other approaches that I don't think are applicable as is (the string pull method for example or moving average without some catchup)

As thing currently stand, the settings for the pen modeler are not tunable (mass and spring constants cannot be changed) so maybe that could be a first step.

I have a few other ideas I want to try

• catch up + prediction : the pen modeler always has a part of the stroke that's final and another that's temporary and is used to play catch up to the pen position. But it's only catchup (and you could also extend it by a little bit as the last event will be ever slightly behind the real pen position). Not really helping with smoothing though.
• Kalman smoother : try to fit the pen input to a dynamical system that's more or less smooth and use error estimate to consider the start of the stroke up to a point to be final (and the rest is not, waits for the next input event, recompute the best estimate
• Maybe some other method ? (doing ML to find a good model ?)

In any case I need to collect some raw data + experiment a little and prototype/test it before deciding what's the best way to improve the model.

I still want the end model not to force the user to write slowly (that's kinda the case on average method without catch up), and I also want to check where the end stroke ends up compared to the raw input data stream. There's other objectives that can end up here as well (like doing some compression on the fly to reduce file sizes).

I'm pretty sure the modeler + app characteristics (input delay, fps) make it so that it's possible to deduce what app is used only from how the handwriting looks.

What's your pen hardware?

I'm on a Lenovo Yoga X1 with an Active Pen 3. 60hz screen. The Yogas are pretty similar to the Microsoft Surface laptops.

I guess you've done a round of different solution you could try. If you have found one in particular that feels nice for some reason I'm interested to know which one.

Xournal++ has great pen smoothing (or input stabilization as they call it). My settings are a deadzone preprocessor of 2.5 and an averaging method of 'arithematic mean'. Their github issue #2320 is pretty in-depth.

Krita overall has good stabilization as well, both the dynamic brush, where you adjust mass and drag (which might be similar to the mass and spring of the current modeler?), and the stabilization options for the default brush. It's open source so you could take a look and see how their stabilization engine works.

Nonetheless I've never experienced 'bad' pen stabilization.

Hope that helps.