Thank you@dberlow!

pardon my ignorant question, but from what tool is this screenshot from?

pardon my ignorant question, but from what tool is this screenshot from?

Hey, I don't think it's really public, but I was curious and found it:https://variable-type-tools.appspot.com/

pardon my ignorant question, but from what tool is this screenshot from?

Hey, I don't think it's really public, but I was curious and found it:https://variable-type-tools.appspot.com/

There was a reply out-of-thread-order (likely by email) here:#463 (comment)

pardon my ignorant question, but from what tool is this screenshot from?

Hey, I don't think it's really public, but I was curious and found it:https://variable-type-tools.appspot.com/

There was a reply out-of-thread-order (likely by email) here:#463 (comment)

ah, thank you! And thank you for Inter. It's one of the few fonts I enjoy everytime I see it. One of the few where I don't mind seing it being used more and more and I still love it. It's such a joy to see it and how readable it is even in small sizes. ❤️

Are you panning any major updates between now and then?

Yeah, there's a lot more coming over the next few months. 99% of the changes will be to the opsz masters, which is a new addition currently not in the stable release.

For GF, I would wait to review this for an update until the opsz work is done or at least at a release quality. The most recent stable release (without opsz) isv3.19

How are you testing this? Did you make sure that it sources the correct font file?

Also, I'm testing this by using the Inter lab (https://rsms.me/inter/lab/) and using DevTools to replace the fontInter-v3_19 withInter V.

How are you testing this? Did you make sure that it sources the correct font file?

Also, I'm testing this by using the Inter lab (https://rsms.me/inter/lab/) and using DevTools to replace the fontInter-v3_19 withInter V.

That is probably not going to work, in any case I can’t help you with that approach. Sorry

Well, I also tried to use Inter V in a test webpage with thefont-variation-settings set to"opsz" 32, but it still doesn't work.

Edit: by using the font locally

Works just fine for me:https://rsms.me/etc/inter-opsz/

Works just fine for me:https://rsms.me/etc/inter-opsz/

That works great. Maybe it only works with the WOFF2, and doesn't work with a TTF?

Many capital letters in the opsz designs are copies from the non-opsz designs (but far from all.) For now. There's a lot of cleanup work to be done first from the UPM conversion (Glyphs.app shifted most Bézier handles on curves 1dp off center which means thousands of manual edits need to be done.) Once that work is complete I'll start looking into improving the design of the opsz glyphs.

(Keep in mind that the opsz work is in progress and maybe 20% complete)

Latest build (updated link in top post) has several capital letters redesigned (opsz=32,wght=400–900, wght 100 is unchanged.)

Also, the slant uses negative numbers (-10 to 0).

Italic letters seem to be a little wacky...>
Onhttps://rsms.me/etc/inter-opsz/ but I set font-style toitalic using DevTools.

That is faked italics from your browser.
With the single variable font you need to use the slant (slnt) axis.
There is no family connection to a separate italic font in this case.

That is faked italics from your browser. With the single variable font you need to use the slant (slnt) axis. There is no family connection to a separate italic font in this case.

Even if it's fake, I wouldn't think that it would normally slant that much.

That is faked

Even if it's fake, I wouldn't think that it would normally slant that much.

The excessive slant is a sign that it is faked.
That is what makes it fairly easy to recognize.
Regardless, when the single variable font is used (as on that page rather than the separate Regular and Italic variable fonts) there is no 'italic' only the slant axis.

Sadly, that makes Inter V incompatible with other fonts:

Nice catch. I had fixed it but forgot to upload a recent font file to thehttps://rsms.me/etc/inter-opsz/ demo. Done now.

Before:

After:

Slant seems a bit weird with opsz 32 letters...
[image]

I have barely started on the italic/oblique design. Consider it non-existent for slnt>0, for now.

Okay, latest beta has a lot of italic/slanting glyphs fixed for opsz>14

Nice!

Good catch. Thanks!

Good catch. Thanks!

I like to help out as much as I can! 😁

Here are some other characters that get messed up.

This issue affects all of Inter V, but not "normal" Inter.

Fixed and a new build has been uploaded. Get it fromthe link in the top message

Changesets:08b522a and59728bc

Fixed. New build uploaded.

I don't think Inter has full Arabic support yet. It just has a couple of new currency symbols.

Probably the glyphs for those specific Arabic characters got updates (see the aforementioned currency symbols), but the rest of the arabic glyphs didn't get any changes.

No, Sir. I've checked it. Version 3.19, Inter-4.00-e77ce318de, and two or three versions before this looked amazing. No issues

Did you now using this font on Android@esqienes?

This likely happens because you have your font chain (aka font fallback) setup with Inter overriding an Arabic font. Inter contains two Arabic glyphs (as you've noticed) which Android will use instead of the glyphs from whatever Arabic font is after Inter in your font config. To "fix" this you need to give your Arabic font higher priority than Inter. (I'm not an Android user, so I can't help you with how to configure Android.)

Sounds like a Figma bug. Having worked on Figma, I happen to know that the "organization fonts" feature has some dedicated font parsing code, separate from what the editor uses, and so it isn't subject to the same hight quality standards and is more likely to be buggy. If I were you I'd report the issue to Figma. I'm sure they would appreciate it.

FYI, I sent in a support request with the InterV.var.ttf file from the Inter-4.00-3f174fcef6 download and they replied with this:

It seems the issue comes from your font file itself, it seems to have missing or invalid fields indeed. Could you see if you have the possibility to generate a new font file for it as this one may be damaged?

Just tried uploading the same file from the Inter-4.00-00e4135b78 build and still get the same error unfortunately.

Hey there@rsms, when do you think Inter is ready to upgrade for Google Fonts? Issue tracking is ingoogle/fonts#3429, but there hasn't been any progress for half a year. My thinking would be to onboard v3.19 for now, then onboard v4 once it's stable. CC@davelab6

@applecuckoo Onboarding 3.19 now sounds like a good idea.
Version 4 is at least a month or so away from being ready.

I do think that having a font without opsz, but having the style of 32 opsz, would be a nice idea. Not just for Android ROMs, but also for apps that don't support variable font options (or only support a list of font weights like Regular and Bold). 🧐

If you download"Inter v4 beta 1" you'll find individual static font files for every "instance", which includes dedicated fonts for Display and non-display.

Can I install the fonts alongside the variable display font?

Would you mindfiling an issue for this? Thank you

Sure thing! Created an issue. Thanks!

#576

Anything that uses shape-shifting rendering (like ClearType on MS Windows or GNOME configured this way) will always have imperfect spacing. Earlier versions of Inter didn’t even include TrueType hints by default because so many people were confused why it looked different for them compared to other people using software without shape-shifting rendering. Glad to hear KDE does a better job. AFAIK, GNOME is capable of quality text rendering but may require some patching and/or configuration. For example, the ElementaryOS team did a good job with improving text rendering quality in GNOME.

I was using Inter.otf (unhinted) in the last two screenshots provided, so no hinting applied. The spacing seems to be caused by a font weight change that I have brought up multiple times now but no one is acknowledging it. Can anyone confirm that there were very recent changes to the font weight? Even if extremely small, anything?

If anyone can confirm the weight changes then the "weird spacing" issue is not a bug. I've noticed that while some letters are one more pixel apart from each other, some other letters are now one pixel closer to each other (compared to last beta). So that tells me that the letters just shifted a itty little bit to accomodate the font weight change (which again, no one seems to acknowledge after bringing it up multiple times).

There was also the issue with monospaced numbers being used in place of regular numbers, which I thought was a bug. The following screenshot shows the system calendar view and the calendar app of GNOME 42, side by side:

I have confirmed that the system calendar does indeed call fortnum by default, but since Inter Beta 8 did not showtnum in the clock before then it makes sense to me thattnum support for Inter was added fairly recently because it only started showing Beta 9. Can anyone confirm thattnum was added to Inter fairly recently? It seems Beta 8 didn't have it, but Beta 9 does.

@AchillesBoi Beta 8 did have tabular numbers (I have just confirmed this), but it appears that the style was updated between 8 and 9 to add the bottom serif on the "1". In your screenshot of June 12 "BETA 8 (normal numbers in clock)" they are visible as tabular numbers, notice the "11" in the calendar (in particular the spacing between the ones, those are not proportional figures).

I believe what you've been seeing has always been the tnum version, it's just that their style has been updated with the serifs.

Thanks for your hard work,@rsms!

We (GitLab) recently updated from4fc901f tofd99812 (4.0-beta7 to roughly4.0-beta9g). The variable font size increased from ~264KB to ~325KB which is a ~23% increase. Is that expected?

I understand the downsides, but FreeType (font renderer used in screenshot) does not currently use stem-darkening, so using the non-hinted Inter at 9pt for GNOME's UI is very hard to read.

Note that GNOME renders and composites all text (incorrectly) in gamma colour space rather than linear, so you do not want to use stem darkening with GNOME. The use of gamma compositing already makes the antialiasing look darker than it should, which compounds with stem darkening to make fonts look too heavy or bold. The Freetype folks generated aBlending Examples chart which demonstrates this problem. The first column is gamma incorrect rendering (what GNOME does). The second column is gamma-corrected rendering without stem darkening. The third column is gamma-corrected renderingwith stem darkening (this is the mode recommended by Freetype devs). The fourth column illustrates what would happen if you enable stem darkening without using gamma-corrected rendering (this is why you don't want to use stem darkening on GNOME). The Freetype folks have adocumentation page that covers this and a bunch of other details. That said, I'm aware that some people do enable stem darkening as a hack to work around the fact that rendering text with incorrect gamma causes light text on a dark background to be hard to read.

Regarding glyph kerning, the main problem with older GNOME apps using Gtk 3 (like most apps on GNOME 42) is that the font rendering method only supports glyph advances which are an integer numbers of pixels. As a result, it's very difficult to get a consistent, even spacing between glyphs. Using GNOME Tweaks to enable the "Full" hinting mode which does horizontal hinting (the default "Slight" is vertical hinting only)may result in more even glyph spacing if the font has high quality hinting, but this comes at the expense of glyph shape and weight accuracy. Inter's automatically generated hinting does not provide good results in this mode.

Newer GNOME apps using Gtk 4 (there's a lot more of them starting with GNOME 43/44) use a font rendering method which renders fonts unhinted, and performs sub-pixel glyph positioning both vertically and horizontally. This results in accurate glyph shapes and weights, and doesn't require rounding glyph advances to pixels, so the glyph spacing is nice and even. Inter looks very good in these applications. This comes at the expense of text rendering getting blurrier, and removing support for sub-pixel antialiasing. Note that "GNOME Shell" (the desktop panel, etc) still use the old font rendering method on current versions of GNOME.

Before end of the year

Hello@rsms , these updates look great!
Maybe there is a more specific release date of a stable version? Curious, since current v3.19 is said not to be updated after the release of v4. Is that correct?

That doesn't look right.
I spent some time digging into this and the issue seems to be using roman reference fonts with ttfautohint while hinting the italic fonts.

With XXX which uses dedicated italic reference fonts for hinting, it looks correct for me in Windows 10 (screenshot from WordPad):

@mol Could you please try this new build and tell me if that resolves the issue for you?
https://d.rsms.me/tmp/Inter-4.0-4b0a834715.zip

Re variable font: The variable font does not have TrueType hints which Windows uses to alter the shape of letters (MS's implementation is called ClearType.) Your original issue is due to suboptimal TrueType hints in the static fonts. The variable fonts won't have the problem simply because there are no hints! However the variable fonts will render differently (on Windows they will render "smoother" and less pixellated than hinted fonts.)

Here's a comparison of ClearType on Windows 10 with static fonts (which has TrueType hints) and standard greyscale rendering (as you will find on/in iOS, macOS, Figma etc)

@rsms that build you shared solves the issue for me, thanks! 😃

Excellent. Thanks for confirming that.

Glad to hear you like it. My aim is "before the end of the year." It's basically done now but there's maybe a week or so of work remaining with QA and the website

Thank you for the answer. Happy to hear that!