FTFactory.java: Fonts loaded by Pango are never registered and always return <null>

Maurice info at cuhka.com
Thu Mar 3 16:40:27 UTC 2016

I'm running on Ubuntu desktop, and I can gladly report that it works 
fine. I think I saw fp wasn't null, but I'll check later. Maybe my only 
fix was ignoring a 'false'.  According to 
FcConfigAppFontAddFile returns a FcBool, and I did see the rc is 0.

Although ignoring the result does work, can it be something that is 
lacking in the environment? The Yocto embedded Linux is naked from the 
start, so it is totally possible that something else is missing.

(my pride on finding the flaw is quickly diminishing...)

Op 03-03-16 om 17:20 schreef Philip Race:
> Since I don't see any code here that looks like it would run only on
> an embedded environment then I wonder why Linux desktop users
> are not reporting the same problem ?
> Did your instrumentation check that both dlopen & dlsym succeeeded ?
> -phil.
> On 3/3/16, 7:43 AM, Maurice wrote:
>> Hmm....  I think I have to agree with you... you are right. 
>> Commenting it in didn't give a compiler or linkage error, and it made 
>> it work. I'm happy at the moment and tired of the debugging process, 
>> but I'll give it more thought later.
>> Op 03-03-16 om 16:36 schreef Mario Torre:
>>> On Thu, Mar 3, 2016 at 2:48 PM, Maurice <info at cuhka.com> wrote:
>>>> At the moment the embedded environment I'm using is not able to use
>>>> downloaded or external supplied fonts. I've traced through the 
>>>> system and
>>>> found that it looks like it fails in pango.c 
>>>> FcConfigAppFontAddFile, at
>>>> least OSPango.FcConfigAppFontAddFile returns false, thus 
>>>> propagating a null
>>>> all the way up.
>>>> Checking the pango.c file I noticed something very interesting:
>>>> JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
>>>>      (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
>>>> {
>>>>      static void *fp = NULL;
>>>>      if (!fp) {
>>>>          void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
>>>>          if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
>>>>      }
>>>>      jboolean rc = 0;
>>>>      if (arg1) {
>>>>          const char *text = (*env)->GetStringUTFChars(env, arg1, 
>>>> NULL);
>>>>          if (text) {
>>>> //            rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
>>>>              if (fp) {
>>>>                  rc = (jboolean)((jboolean (*)(jlong, const char 
>>>> *))fp)(arg0,
>>>> text);
>>>>              }
>>>>              (*env)->ReleaseStringUTFChars(env, arg1, text);
>>>>          }
>>>>      }
>>>>      return rc;
>>>> }
>>>> Yes, you see it correctly! The line that actually should register 
>>>> the font
>>> Pointer to functions make me blind too, but If I'm not reading it
>>> wrong, I think this is not a commented code call, it's meant to tell
>>> what the code below it does (apparently, it made blind also the
>>> author!):
>>> FcConfigAppFontAddFile is dloaded into fp, so this totally
>>> incomprehensible line:
>>> ((jboolean (*)(jlong, const char *))fp)(arg0, text);
>>> it's just casting fp to a function that returns a jboolean and takes a
>>> jlong and a const char array as argument, hence it becomes again:
>>> (jboolean)FcConfigAppFontAddFile(arg0, text);
>>> Cheers,
>>> Mario

More information about the openjfx-dev mailing list