Who likes non-destructive transformations, and floating-point coordinates?

Great topic! Imprecise “smart” stuff is a trade off for sure. This is why I don’t use Smart Components in Glyphs for things like circled glyphs or small caps and instead use Tim Ahrens’ RMX Scaler and Tuner. The RMX tools try to maintain consistent stem widths, whole numbers, and so on, so there’s less manual adjustment I have to do. One downside is that this leads to a larger variable font file, compared to Smart Components (which are actually variable components), but WOFF2 is good enough at compression that I think it’s an OK trade off.

When it comes to things like smart corners - for serifs and so on - I use them early in the process, and maybe by the time I’m done, I’ll have decomposed some or all of them. It’s not even because of floating point rounding, I just find it’s not always ideal for the design, even when I go through the steps of making  fairly elaborate corner components with multiple widths defined etc. But I have inconsistent beliefs about this based on context - yes I will decompose a corner component to get a serif just how I want, but what about the bar on an hbar, for example, and stuff like that? I will absolutely scale components like a bar imprecisely, and not care about it.

All that to say, I haven’t really found a perfect workflow for all these “smart” features. But I do think that totally non destructive transformations are not always ideal. And I can always throw those things into a backup layer before decomposing if I feel it’s important to keep around in some form. You can definitely go wild and write scripts to round things for you and make sure that everything is as non destructive as possible, but at that point the time invested might not be as valuable as I want, especially because part of my goal with source files is their long term preservation and utility - I don’t know if all these editor specific features will last 

jeremy tribby said:

One downside is that this leads to a larger variable font file, compared to Smart Components (which are actually variable components), but WOFF2 is good enough at compression that I think it’s an OK trade off.

This will be true at some point when the VARC proposal is accepted into OpenType and added to renderers, but for now "variable components" don't exist in the binary, and all the smart stuff gets decomposed into ordinary paths when the font is compiled.

If Smart Components are reducing your binary size, you are living in the future. 😎

Floating point coordinates can be a good idea to get better interpolations and extrapolations. Here is an example of extrapolating the tail of the /Q. The lower left and middle tails in the picture were given rounded coordinates. For both tails the tangent control handle is quite accurate. However, the tangent handle of the extrapolated tail (top right) is clearly not tangent:

@Linus Romer: As rounding after extrapolation would at worst move the final point by half a font unit in each of X and Y, I don’t think rounding is the “villain” here.

If the angle of the line changes, AND the relative length of the two segments is different, then there will be such kinks in both interpolation and extrapolation, even without rounding. That appears to be what you are getting here.