TextMesh Pro Expose overloads of TMP_FontAsset.CreateFontAsset that take byte[]

I noticed that as of the move to the new TextCore APIs, there's now a CreateFontAsset method that takes a Font as a parameter. However, while the TextCore APIs can also take a byte[] instead, TMP doesn't expose this functionality.

Currently I'm using a customized version of the TMP package that has this functionality added in, however it would be immensely useful to not have to reimplement this each time TMP updates. The use case is for loading .ttf/.otf fonts at runtime, without using asset bundles.

I suppose an alternative solution would be to offer an API to get a Font from the bytes of a .ttf/.otf font file.

 

Can you please explain show your solution, even if it's just for the current tmp version

 

In the latest preview release of the TMP package, the following function was added.

Code (csharp):

1.  
2. public static TMP_FontAsset CreateFontAsset(string familyName, string styleName, int pointSize = 90)

Where the font asset will be created from a System / OS font (if available). This function bypasses the creation of a font object which is more efficient from a memory standpoint.

The above function does not expose all parameters and actually ends up using an internal function that uses the file path of the font file. This internal function could be made public.

Given the above, do you still need the ability to create a font asset from a byte array given we can create one from the font file directly?

 

I'd say having to create the font from a byte array is the most important. For instance in a WebGL app you may not be able to dynamically download a remote font to local storage, so having it in a byte array is the way to go.

 

For me as well, our app targets mobile and webgl, and we need to download and cache arial unicode (20mb).
So my guess is byte array is the way to go.
Maybe loading from native tff/otf path can work too? As long as it can be serialized i guess, as unity font is not serializable.

Edit: I forgot to mention, the TMP_FontAsset also needs to be dynamic, as I can't create 2k+ gylphs at runtime. So would a byte array solution still work?


As I have noticed the font path method passes null for font, so the sourceFontFile would not work huh?

 

I just turned TMP_FontAsset into a hierarchy of classes (TMP_MemoryFontAsset, TMP_ExternalFontAsset, etc) and added new methods to them that called the appropriate methods on the FontEngine class. Then I just changed all the places that used FontEngine.LoadFontFace etc to use these new methods.

 

I think it would be quite valuable to have both the file path and byte array APIs (or, alternatively, a Stream API). It may not be desirable for the font to be located directly on the filesystem (it may be loaded from a compressed archive, or retrieved over the network).