Issue loading HTML5 font at runtime

#1

I have a related problem to Font Embed Error. I am creating a manifest at runtime, using manifest.addFont, manifest.addBitmapData, manifest.addText, and manifest.addBytes. After doing that I make a call to AssetLibrary.loadFromManifest (manifest). All my assets load, except for the fonts. When I trace out my manifest, it appears to be okay:

{
assets : [{
		path : assets/title/haxe-opt.svg, 
		id : assets/title/haxe-opt.svg, 
		type : TEXT, 
		preload : true
	},{
		path : assets/title/frontPageText.html, 
		id : assets/title/frontPageText.html, 
		type : TEXT, 
		preload : true
	},{
		path : assets/title/KatamotzIkasi.eot, 
		id : assets/title/KatamotzIkasi.eot, 
		type : FONT, 
		preload : true
	},{
		path : assets/title/KatamotzIkasi.ttf, 
		id : assets/title/KatamotzIkasi.ttf, 
		type : FONT, 
		preload : true
	},{
		path : assets/title/KatamotzIkasi.woff, 
		id : assets/title/KatamotzIkasi.woff, 
		type : FONT, 
		preload : true
	},{
		path : assets/title/KatamotzIkasi.svg, 
		id : assets/title/KatamotzIkasi.svg, 
		type : FONT, 
		preload : true
	}], 
libraryArgs : [], 
version : 2, 
libraryType : openfl.utils.AssetLibrary

}

You may recognise KatamotzIkasi font from the OpenFL samples. I ran the AddingText example which works because it bundles the fonts at compile time.
I also noticed the CSS font loading issue but this is not limited to Safari for me. Any ideas?

I don’t get an error, the font just doesn’t load. OpenFL 8.8.0, Lime 7.2.1.

Sorry I posted this originally in a different less relevant thread. :slight_smile:

1 Like

Font Embed Error
#2

I think we only support loading fonts by name on HTML5, what does the standard asset manifest generated by the Lime tools look like?

0 Likes

#3

Thanks Joshua, getting back to this now…
So as the average reader might know, compiling assets in the conventional way results in a manifest being created in the compiled application. In the AddingText sample I inserted a console.log(manifest); and got the following:

{…}
assets: (4) […]
0: {…}
    id: "assets/KatamotzIkasi.eot"
    path: "assets/KatamotzIkasi.eot"
    preload: true
    size: 24462
    type: "BINARY"
    <prototype>: Object { … }
1: {…}
    id: "assets/KatamotzIkasi.svg"
    path: "assets/KatamotzIkasi.svg"
    preload: true
    size: 55940
    type: "TEXT"
    <prototype>: Object { … }
2: {…}
    className: "__ASSET__assets_katamotzikasi_ttf"
    id: "assets/KatamotzIkasi.ttf"
    preload: true
    size: 24264
    type: "FONT"
    <prototype>: Object { … }
3: {…}
    id: "assets/KatamotzIkasi.woff"
    path: "assets/KatamotzIkasi.woff"
    preload: true
    size: 13592
    type: "BINARY"
    <prototype>: Object { … }
length: 4
<prototype>: Array []
libraryArgs: []
length: 0
<prototype>: Array []
libraryType: null
name: null
rootPath: null
version: 2
​

What I find interesting is the asset type varies between FONT, BINARY, & TEXT depending on the file extension. Where should I go from here? Is this the “standard manifest” you suggested?

0 Likes

#4

We only embed fonts using CSS right now, but Font.loadFromFile could possibly be implemented for HTML5 – the problem is that we have multiple files, so I guess it would be Font.loadFromFiles as a proposed API to add new CSS to the parent page.

The “loading” step on HTML5 for fonts (currently) is to wait until the page has loaded the font from CSS. We don’t actually initiate the transfer currently

0 Likes

#5

Aha, good to know. I think my current needs could be met by simply building my own CSS. I’ll go that route for now as long as that works. Thanks!

0 Likes

#6

Adding Font.loadFromFiles for runtime generation of CSS could be interesting, so if you decide to go that route, it could be a neat thing to share :slight_smile:

0 Likes

#7

I would LOVE to have “openfl contributor” on my resume. Definitely will consider this!

0 Likes

#8

You can feel free to join the chat at https://discord.gg/tDgq8EE if you want to dig into this later :slight_smile:

0 Likes