In fact, it turned out that the libLASi-1.1.0 version of MissingGlyphExample.cpp did not verify this bug. So I looked more carefully at the PLplot results, and the first problem of this kind occurred for Unicode U+2648 = ♈.
So I tried that glyph in MissingGlyphExample.cpp using the following patch: -----------------------------------8x------------------ --- MissingGlyphExample_original.cpp 2008-02-08 17:27:56.000000000 -0800 +++ MissingGlyphExample.cpp 2019-01-09 11:47:55.134114211 -0800 @@ -22,7 +22,7 @@ // doc.osBody() << setFont("Arial") << setFontSize(18) << endl; //char testString[]={0xe2,0xab,0xb4,0x00}; - const char *testString="Unicode U+2AF4 — U+2AF8 glyphs are : ⫴⫵⫶⫷⫸."; + const char *testString="Unicode U+2648 glyph is : ♈"; // // Show the string: // -----------------------------------8x------------------ and after configuring and building libLASi-1.1.0 with the above patch applied using cmake <path to top-level of the libLasi-1.1.0 tree> I got the following result that is a simple (non-PLplot) verification of the issue. irwin@merlin> make; examples/example0 >| test.ps ; echo "return code = $?" [ 15%] Built target documentation [ 53%] Built target LASi [ 69%] Built target example1 Scanning dependencies of target example0 [ 76%] Building CXX object examples/CMakeFiles/example0.dir/MissingGlyphExample.o [ 84%] Linking CXX executable example0 [ 84%] Built target example0 [100%] Built target example2 Error returned from FT_Load_Glyph return code = 1 Both of libLASi and gucharmap depend on similar subsets of the GTK+ suite of libraries. Therefore, I looked up U+2648 using gucharmap, and for that GUI, that glyph renders properly without issues. With gucharmap you can specify a particular font preference which fontconfig processes to come up with the actual font used to render the glyph which you can discover by right-clicking on the glyph. When I did that, the actual font used for the gucharmap rendering of this glyph was the Noto Color Emoji font from the fonts-noto-color-emoji package. So I temporarily removed that font package, and all was well with the above examples/example0 test *and* PLplot testing of our psttf device driver as well. So it appears that GTK+ applications such as gucharmap can render glyphs from Noto Color Emoji with ease, but libLASi currently throws an error on those. So that is an upstream bug in libLASi which I likely cannot fix without expert help. I will attempt to get that help from the upstream libLASi developers who I was associated with in the past, and if I get that help I can certainly make another libLASi bugfix release that deals with this issue. But just in case I cannot find them at all please let me know if you have some ideas about how to fix this libLASi bug. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________