Re: [Plplot-devel] Qt(5) problems

[Alan W. I. <ir...@be...>]

On 2017-08-30 16:17-0000 Schwartz, Steven J wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: 28 August 2017 22:39
>> To: Ole Streicher <deb...@li...>
>> Cc: plp...@li...
>> Subject: Re: [Plplot-devel] Qt(5) problems
>>
>> On 2017-08-28 15:06+0200 Ole Streicher wrote:
>>
>>> [...] since Qt4 is going to be deprecated very soon in Debian [1]
>>
>> [...]
>>> [1]
>>> https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html
>>
>> By the way, thanks very much for that link.  I had no idea that upstream Qt4
>> maintenance had completely shut down so that the demise of downstream
>> Qt4 on most Linux distributions is inevitable and likely soon even for non-
>> Debian distributions.  Let's just hope this focus of the upstream Qt
>> developers on Qt5 will soon make that suite of libraries as reliable as the Qt4
>> suite of libraries is now.
>>
>
> For Mac-related reasons we have been using Qt5 for some time now for our QSAS software, which as you know uses plplot as its graphics engine. Actually, we use our own qt driver rather than the official plplot versions for reasons I don't know but probably related to the way we bind it into our code and/or the way users have to interact with the plots. But we've kept the plplot core reasonably up-to-date.
>
> Our big issue with Qt5 is the placement of characters/symbols on the plot page which is rarely at exactly the right vertical location and varies from one output device to the next. I think that was one of the main issues which led you to revert to Qt4. Perhaps there are others.
>
> Do you have any updates (or optimism) on this issue?

Hi Steve:

Yes to an update (see below), and because users like you and me are
sensitive to this issue, I was completely optimistic that Qt5 will
eventually be fixed in this regard (or that may have already happened
for the latest upstream version). However, from your experience it
sounds like that has not yet happened for the Mac OS X versions of Qt5
that you have tried so far, and my experience is mixed in this regard
for the Linux case (see below). My advice is to keep trying the latest
versions of Qt5 (e.g., an unpatched upstream version that you build
yourself) to see if/when this issue has finally been settled
completely.

Now here is my Linux experience concerning this issue.

Some years ago I designed an extremely sensitive test for character
alignment called examples/python/test_circle.py. The idea of this test
is to superimpose the same UTF-8 glyph at the same position for a wide
range of different character sizes.  If the font designers have
centred the glyph within the glyph box, then all those different sized
versions of the same glyph should line up exactly, but otherwise the
effective position changes with character size in a way that is
extremely sensitive to misalignment issues.  Of course, some glyphs
like an asterisk (which you can see from the example) are
fundamentally not centred by design, but in practice (at least for my
particular set of system fonts) I find the UTF-8 "heavy multiplication
x", "number sign", "four teardrop-spoked asterisk", and "8-spoked
asterisk" tend to be aligned consistently with each other, and
typically only tiny vertical adjustments (a small or zero fraction of
the character height) are needed to remove all misalignments for all
character heights for those particular glyphs.

The historical result for the above test was I found no vertical
alignment issues at all for Qt4 (zero offset adjustment needed), and
although an earlier Qt5 version (5.3.1?) that I built myself required
a large offset adjustment of -0.63 character heights I was able to
change that adjustment to zero and get good results for the above test
for an early version of Qt5 5.3.2 that was available for Debian
Jessie.  So I thought that Qt5 vertical alignment issue was settled
as of Qt version 5.3.2.

But I tested again just now to be sure of my answer to you, and the
ideal offset for Qt4 remains close to zero (I found best alignment
occurred if the offset adjustment was -0.035 character heights), but
for Qt5 it is now changed from zero to +0.46 (!) character heights for
most qt devices (with the exception of svgqt which appears to still
continue to need no offset correction).  Note this is still called Qt5
version 5.3.2, but I assume patches have been (incorrectly) applied to
it that have reintroduced the vertical alignment issue compared to the
earlier 5.3.2 version from Debian Jessie that I tested before.

Because this appears to be a Debian-specific issue for an outdated
Debian distribution and very likely not an upstream issue, I
ultimately decided to continue with no vertical adjustments for either
Qt4 or Qt5.  However, once I update to Debian Stretch (which provides
libqt5 version 5.7.1 (!)) I will look at this issue again, and I
remain optimistic no alignment fix will need to be made in that case
(since there appeared to already be a solution for at least one
variant of the 5.3.2 version of Qt5).

You may also want to look at this issue for yourself using the git
master branch version of PLplot and the above
examples/python/test_circle.py test.  But it appears from my Debian
Jessie experience that patches applied by packagers can screw up Qt5
vertical alignment quite easily so for that test I would suggest one
Qt5 version you should try is one you build yourself with source code
straight from the latest Qt5 upstream developers without any patches
applied at all.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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
__________________________