Font System Improvements with ae23.5_13 exposing issue with Poppins typeface

[-_-_+]

We have a mix of windows and MacOS machines, with a mix of AE versions. when creating a project on Windows, AE 23.0.0, using the 'Poppins' typeface from Adobe Fonts, it creates a version seemingly incompatible with AE latest Beta (23.5x26) on MacOS, showing as [Poppins-Light/Type1].

When opening the project in AE 23.3 on MacOS, it shows (renders and in the character dropdown) fine, but the render times are >100x slower (123ms vs 1ms). I can resolve this by switching the font from 'Light' to 'Standard' and back again. 

If the resolved project is then opened again on Windows, AE 23.0, the issue returns, and the typeface gets replaced with the windows specific version.

Seemingly, the improvements to the font system are now exposing that something incorrect is happening in the background.

I've included 2 project files, 1 that includes the windows typeface, and shows slow render times on MacOS 23.3, and incompatible Typeface on AE 23.5. The other file has the issue resolved for MacOS.

1. Version of the app: 23, 23.3 and 23.5x26

2. Platform and OS version: MacOS 13.3.1 (a) (22E772610a) and Windows 11

3. Basic steps to reproduce the problem:
As far as I can tell, this occurs solely with the mix of windows and mac, and with 'Poppins'.
create a new project on windows, using AE 23, create a text layer, use poppins light, save
open on MacOS, inspect render times

4. Expected result and actual result:
identical typeface render times / automatic handling of different versions accross various OS

[Douglas_Waterfall]

Thank you for starting this conversation, and the detailed information collection - and trying out the beta!

I do not quite know what the answer is, but let me explain what is new in the beta which might help start sorting this out.

There have been complaints about the Poppins experience before, and I had assumed months back that it was due to duplicate fonts - Adobe Fonts has a version, and there are statically installed version. OpenSans and SourceCodePro have resulting in (as I read it) similar odd behavior.

The big change relevant here is that the new code, let me just call it the FontServer, is much, much pickier about what it accepts as a match when opening a project. Behind the scenes the Project file stores a tupple of data about the Font that is being used in an Layer - (PostScript name, something_else1, and Technology). If the font is a Variable font the design vectors are stored as well.

On Project open the FontServer is asked to find an installed Font which matches that tupple and the new code requires that it match exactly. The previous verision of the code let some other piece of code make the decision and that code was much more permissive about matching, preferring I think the view here is something close enough. In the context of a Variable font, this lead to mayhem (and crashes) and so this more precise version was implemented.

If the FontServer is unable to find an exact match it creates a Substitute Font for the requested tupple and that is what you see with your naming [Poppins-Light/Type1]. As far as the FontServer is concerned, that is the end of it - you asked for Font, you got a Font.

Now, the Project open process is not done and it looks for these Substitute Fonts and goes and asks Adobe Fonts (in the cloud) if it knows about these fonts by PostScript name. If it comes back and says yes, then the known fonts are activated in the background - that is the end of the Project open process.

Note that the only criteria for activation is PostScript name, we are making no claims that it was an exact match to what was used to create the original Project. All we have done at this point is trigger an activation and download of the font.

But, we are not done yet. As the Fonts show up the FontServer is called to process them and it checks to see if there are any Substitute Fonts which match the newly installed Fonts by PostScript name. If any do, then we kick off a font replacement process where all the usages of a Substitute Font are replaced with this real Font.

As this is tied to the background Font activation there is a noticeable lag between Project open, the first draw of the Substituted Font, and the replacement re-draw. This whole process is much more reliable than before - sometimes it used to end up with scrambled glyphs which hopefully I've entirely eliminated.

So that is the general process that occurs around missing fonts.

There is a bug/limitation that I working on as we speak which addresses a gap that you might have just realized.

What happens if there is already an installed version of Poppins which does not match the persisted Project Font information but DOES match the PostScript name? At the current time we do not handle this, and always prefer the Adobe Font version. Likewise, we sometimes will fail to do the replacment when Adobe Fonts does not even know about the Font at all.

All of this is of course because the Font instance which was used to create the Project is long gone, and so we are forced to try to make do and the replacement process is how we do that. If the original Font can be re-installed, or the Project re-saved with the new instance than subsequent opens will no longer be missing the font.

After writing all of this, I do not have a clear answer to your issue, but I think I know what is going on and once the next fix goes in it should be better about finding the font that already exists on the system.

Douglas Waterfall

After Effects Engineering