remove Snooty "font tweaks"

[sophiapoirier]

Alright I spent some time deconstructing the Snooty font tweaks, why they were needed, what they did, super advanced math measuring pixel positions and whatnot, because I thought you were probably right they we should just offload whatever layout requirements to the client code. The crux of the remaining font tweaks came down to two things:

• Despite being 10px, 10 pixels is not enough vertical space to draw them without the descenders being clipped. 11 pixel region seems to be the minimum. This may just be a VSTGUI quirk, I don't know, but for extra safety, I changed every use of Snooty to use a 12 pixel region height, so no more tweaks for that needed in DGTextDisplay.
• The other issue is that, when entering text edit, the text position jumps upwards a couple of pixels. This is not unique to Snooty but happens with our plugs that use other fonts too, so maybe another VSTGUI quirk, maybe a platform text edit field quirk, I don't know, but with minimum 12-pixel regions, it's not an issue.

So if we just always give Snooty 12 pixels of height in which to draw, it's happy and all of the hackz become unnecessary. At least on my Mac. I have opened this pull request to give a holding pen for you to see whether this approach is also working okay for you on Windows!

[sophiapoirier]

I just added updated plugin screenshots for everything except BO (they have all changed, even those with recent captures) to the 64bit_site_update branch. I know that the state of these for me matches what original mockups looked like. If you want, you could compare what you see there with what renders for you with the various Snooty-imbued GUIs?

I'm sure there is an inevitable bit of variation between how platforms render fonts and there surely are in the other plugins, but it's probably more subtle with aliased fonts. A pixel of difference might be like fighting the tide, but I don't know, I also know it matters in some cases. My thinking is we could either play with things like 11 pixel heights or 13 pixel heights for the text controls and see if the odd vertical are renders more matched, or reintroduce a bit of font tweaking (though I think there's probably a better way to do it than some of the questionable ways that I came up with before, like just actually adjusting the region vertically at creation, rather than fudging the draw region for each draw event).

What do you think?

[tom7]

I agree it's pretty much hopeless for "normal" fonts to get the cross-platform rendering identical. For a pixel font that we control it seems like it should be doable, though? It's possible that it's an issue with the font itself:

• I divide the native "pixel grid" into some arbitrary box size like 4096 and then place the coordinates there (native precision is int16) since this will only be exact with powers of two, there's a possibility that some font engines
• I think I saw an off-by-one error where it rounds negative coordinates in the wrong direction (unlikely to cause the whole font to move by a pixel though?)
  Lemme try these (TODOs anyway) because if we can make the fonts just really portable, that has obvious advantages.

Otherwise, I think tweaking the position by 1 pixel on windows (at creation time) seems like a pretty reasonable option, mainly for the cases where the positioning is really tight in the UI (like my screenshot). At least we don't have cut off text any more, so now we're really just in the polish zone...

[tom7]

OK, I pushed new TTFs in 2fa778c with these changes (which I think are improvements regardless of whether they fix the spacing here). Appearance doesn't change for me. If this moves the font down a pixel for you then that would be good, since then our rendering agrees. Otherwise creation-time tweaks?

[sophiapoirier]

The new version of Snooty actually changes horizontal spacing slightly, and only in good ways (there were a gaps between characters that I now see had an extra pixel of gap between them, and now they don't). No vertical change, though. So I added a somewhat-better-formulated vertical placement hack for windows to push Snooty up by one pixel. How does this look for you? DGHelpBox got uglier than I wish but what you gonna do...

[sophiapoirier]

Ah but now, I guess with the new version of the font, the single pixel of cropping at the top now is back when in text edit mode. I'm not sure if I care anymore at this point... 😞

[tom7]

Oops, I think I was actually testing in the "snooty" branch, which still exists but is not this pull request! Still bad at git, sorry.
After merging the new font in here, I'm able to get the text to line up exactly with a tweak of (0,+1). I guess the dream of having this be tweakless is out of reach for now, but it seems a lot better than it used to be. All LGTM if it still seems good to you.
Text still moves up when in text edit mode (seems ok? maybe this is even deliberate in vstgui?) on Windows, but there's no cutting-off for me.

(overlay of 50% screenshot from 64bit_site_update with windows screenshot)

[sophiapoirier]

Cool! I squashed your last commit down in the previous one and shall merge.

Regarding my discouragement with text edit upward bounce cropping on Mac, I think my appetite for weird platform hacks is lower than when I originally added this stuff, and now I see that I kinda don't wanna futz further because I feel like those are the kind of things that can change from OS version to version, or library (VSTGUI) version to version, and being in that maintenance business is tedious. And while it looks bad, it doesn't really present any functional usage challenge. I'm more inclined to file a bug on VSTGUI and see if they find that maybe they're doing something wrong causing the vertical scoot when entering text edit...

[sophiapoirier]

steinbergmedia/vstgui#218