Bug#918774: Simple method of verifying this bug

["Alan W. Irwin" <Alan.W.Irwin1234@gmail.com>]

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
__________________________