Error while loading fonts (AIR)

chatmurai74

Hi !
Until now, I have tested my project with 'openfl test flash' command to take advantage of the shorter compilation time, but now I need to load external content (jpeg images hosted on a remote server) and Flash Player sandbox policy won't let me do this. To bypass this, I would like to test in AIR with 'openfl test air' but there is an error while loading fonts used in components:

adl[2562:41735] CoreText failed to get font asset: 0 - (null)

In the project.xml file, I do:
<assets path="assets">
<font path="fonts/Montserrat/MontserratLight300.ttf" id="MontserratLight300" embed="true"/>
</assets>

I can compile for Neko without any trouble, but for some reason, compilation time is longer, and I want to be able to compile for AIR at some point.

I suspect that this is more an OpenFL related error, feel free to tell me if I have to ask in the OFL forum instead.

Thanks !

joshtynjala

chatmurai74 adl[2562:41735] CoreText failed to get font asset: 0 - (null)

I just tested a pure ActionScript 3.0 AIR app without OpenFL, and without any embedded fonts. I still see the same message in stdout. With that it mind, it can probably be safely ignored.

chatmurai74

Thanks for your answer Josh, the thing is I could ignore this message if the ADL wasn't showing a nice grey background instead of my app!

Maybe it's not a so smart idea to compile for AIR in 2025, but this Loader + security sandbox thing in FLashPlayer is really annoying.
I gave a try to HashLink too, but it doesn't like my var riders:Array<RiderVO> = data.map((r😃ynamic) in the result() function of the LoadRidersCommand class, so I should probably stick with Neko until I find a solution.

joshtynjala

chatmurai74 Thanks for your answer Josh, the thing is I could ignore this message if the ADL wasn't showing a nice grey background instead of my app!

It sounds like maybe there's another exception being thrown somewhere. Try compiling for the AIR target with openfl test air -debug. This should allow AIR to pop up a window with the stack trace for the exception (though any trace() calls probably won't display in stdout anymore, so it's a tradeoff).

chatmurai74

I followed your advice and tested with -debug option and you were right, it was the Security.allowDomain("*"); that prevented the AIR compiler to run.