Happy Birthday - Rolex for Christmas?

[Irwin]

Get the Finest Rolex Watch Replica !
  
We only sell premium watches. There's no battery in these replicas
just like the real ones since they charge themselves as you move. 
The second hand moves JUST like the real ones, too. 
These original watches sell in stores for thousands of dollars. 
We sell them for much less. 
  
- Replicated to the Smallest Detail
- 98% Perfectly Accurate Markings 
- Signature Green Sticker w/ Serial Number on Watch Back
- Magnified Quickset Date
- Includes all Proper Markings

http://www.chooseyourwatch4u.com/














you stegosaurus me syllabify me  [2


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#918774: liblasi0: response to missing system glyphs no longer works correctly

[Alan W. Irwin]

Package: liblasi0
Version: 1.1.0-2
Severity: important

Dear Maintainer,

Since one of my recent Debian Buster upgrades I have been getting the
following run-time errors with libLASi when a missing system glyph is
encountered:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Error returned from FT_Load_Glyph
Aborted

You definitely don't want libLASi to throw errors and abort when
encountering missing system glyphs because that situation is fairly
common.  Therefore, I have rated the severity level of this bug as
important.

The relevant libLASi code that attempts to do something responsible
when encountering missing system glyphs is the following code in
libLASi-1.1.0 (and also libLASi-1.1.2).

FT_Error error = FT_Load_Glyph(face,glyph_index,FT_LOAD_NO_BITMAP);
if(error){
   //
   //DEBUG:
   //
   //std::cerr << "PANGO is returning a glyph index of " << std::hex << 
glyph_index << std::endl;
   //std::cerr << "but PANGO_GLYPH_UNKNOWN_FLAG is supposed to be: " << 
0x1000 << std::endl;
   //std::cerr << "and PANGO_GLYPH_EMPTYis supposed to be: " << 
0x0FFF << std::endl;
   
   //
   // Substitute something that works: All fonts are supposed
   // to handle glyph_index 0 as the default replacement glyph:
   //
   
evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph"); 
}else{
   evalReturnCode(FT_Load_Glyph(face, glyph_index,FT_LOAD_NO_BITMAP), 
"FT_Load_Glyph");
}

where evalReturnCode is the following inline routine (in both 1.1.0 and 1.1.2):

/** Converts a freetype return code into an exception.
 */
inline void evalReturnCode(const int errCode, const char* funcName) throw 
(std::runtime_error) {
  if (errCode)
throw std::runtime_error(std::string("Error returned from ") + funcName);
}

So the obvious purpose of the above code is whenever there is some
issue with FT_Load_Glyph for a give glyph_index it tries again with
glyph_index = 0 which according to the above notes should always "just work" 
without
throwing an error.

In any case this technique for avoiding throwing errors on missing glyphs worked
perfectly over the years, and I can see no
reason why it has suddenly started throwing errors now.  But since my
recent Debian Buster upgrades did not involve libLASi, this bug should
likely be reported against one of the many dependencies of libLASi,
but I don't know which one so I have started the process by reporting
the bug here.

I haven't tried this myself yet, but I am virtually positive you can
easily verify this issue by building and running
libLASi-1.1.0/examples/MissingGlyphExample.cpp.

Instead of performing that direct test of libLASi, I have been
indirectly testing libLASi over many years via regular PLplot testing
since PLplot includes the psttf device which links to libLASi.  The
examples we test do include missing glyphs, and my recent PLplot tests
have recently started erroring out with the above abort for our psttf
device driver which is the motivation for this bug report.

FYI, I am far from expert with libLASi and C++, but I do have some
familiarity with the libLASi code because I have helped some upstream
with its build system and bug releases over the years (because of my
PLplot interest).

So if there are some further tests you would like me to try because
you are having trouble verifying this bug with
MissingGlyphExample.cpp, please let me know.

Alan

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.10-custom (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages liblasi0 depends on:
ii  libc6  2.28-2
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgcc11:8.2.0-13
ii  libglib2.0-0   2.58.2-3
ii  libpango-1.0-0 1.42.4-6
ii  libpangoft2-1.0-0  1.42.4-6
ii  libstdc++6 8.2.0-13

liblasi0 recommends no packages.

liblasi0 suggests no packages.

-- no debconf information

Bug#918774: Simple method of verifying this bug

[Alan W. Irwin]

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.cpp2008-02-08 17:27:56.0 -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 

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
__

Bug#921139: lasi: is two important bug fix releases behind upstream

[Alan W. Irwin]

Source: lasi
Version: 1.1.0-2
Severity: important

Dear Maintainer,

As primary maintainer of upstream libLASi I note that lasi version
1.1.0 was released in 2008-02-08 and has been superseded since by
three important bug fix releases, 1.1.1, 1.1.2, and most recently (see

1.1.3.  Throughout this series of bug fixes the libLASi CMake-based
build system has remained mostly the same so it should be entirely
straightforward to update your current packaging of 1.1.0 to 1.1.3.

Making these bug fixes available to Debian (and derivative
distribution) users will greatly improve their experience with this
library.  For example, the recent release of 1.1.3 includes a fix for
the important issue reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918774.  So as soon
as you package 1.1.3 to address the current important bug, that
important bug gets automatically fixed as well.

Alan

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.10-custom (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#918774: This bug now fixed upstream

[Alan W. Irwin]

With a substantial effort (learning much more about pango and freetype
than I wanted to) I have now fixed this (and several other) upstream
bugs in libLASi and made a bugfix release 1.1.3 containing these
improvements that has been well tested on Debian Buster.  See
<https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
for the details concerning that release.

So packaging libLASi-1.1.3 (which should be straightforward since the
libLASi build system has not changed that much from earlier versions)
as requested at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139> should
automatically address this current bug report as well.

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
__