|
From: António R. T. <ar...@gm...> - 2018-12-16 00:07:32
|
Hi all
after trying a long time playing with cmake options trying to see if I
could get my qt5 plplot loading suitable f fonts I came to conclude that my
distribution in a way acts differently from Alan's.
I get very nice results if in the file plqt.cpp line 182
where is
f.setFamily(""); // no family name, forcing Qt to find an appropriate
font by itself
I replaced by
f.setFamily("Helvetica"); // no family name, forcing Qt to find an
appropriate font by itself
it seems in my system qt does not find an appropriate font by itsel. I
attach the very nice results obtained only by performed this small change.
cheers,
On Sat, Dec 15, 2018 at 9:38 PM António Rodrigues Tomé <ar...@gm...>
wrote:
> Hi all,
>
> This seems to be a truetype font issue my plots were made without true
> type support. I noticed the difference between Alan plots and mine were not
> only in position and orientation but also in fonts used.
> I have a lot of true types fonts installed but for strange reason none is
> selected.
> only with a package free-ttf-fonts they are selected. result in attach.
> the text orientation is corrected but not the vertical displacement.
>
>
>
> On Sat, Dec 15, 2018 at 4:29 PM António Rodrigues Tomé <ar...@gm...>
> wrote:
>
>> Hi Alan
>> this is indeed very strange.
>> here the result of uname -a
>> 4.12.14-lp150.12.28-default #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f)
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> My distribution is opensuse leap 15.0
>> and my qt is 5.12.0
>>
>> (although i had exactly the same result with 5.11 as i've tested it a few
>> weeks ago)
>>
>> just built again with your cmake suggestion and the results are exactly
>> the same as before.
>> I'l try to get an hand during next week on a computer with a different
>> linux distribution just for testing.
>>
>> cheers,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 14, 2018 at 11:41 PM Alan W. Irwin <
>> Ala...@gm...> wrote:
>>
>>> On 2018-12-12 15:24-0000 António Rodrigues Tomé wrote:
>>>
>>> > Hi Alan,
>>> > now that 5.14 is out I would like to be more useful in solving the qt5
>>> > driver problem. However I do not complete understand the driver system
>>> to
>>> > be of big help.However for me I found a work arround that seems to work
>>> > quite well. I send you 4 files, output of x01 example using qt driver,
>>> png
>>> > and pdf) the ones with Realease in name were created by the actual qt
>>> > driver version 5.14 that I constructed with the command
>>> > cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>>> > -DDEFAULT_NO_CAIRO_DEVICES=ON -DDEFAULT_NO_QT_DEVICES=OFF
>>> DENABLE_cxx=ON
>>> > -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON ../ >&
>>> > cmake.out
>>>
>>> Hi António:
>>>
>>> Please keep this discussion thread on list.
>>>
>>> I think it would be better style (and also I think -DBUILD_TEST=ON is
>>> essential)
>>> to use instead
>>> cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>>> -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON
>>> -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out
>>>
>>> I just tried all those options here (except for your
>>> -DCMAKE_INSTALL_PREFIX), and they worked fine,
>>> i.e., eliminated all bindings other than cxx and qt, dropped the cairo
>>> devices, and included
>>> all qt devices (which happens by default if -DENABLE_qt=ON).
>>>
>>> What is your exact platform (I think it might still be opensuse, but
>>> what version?) and what are the results of the "uname -a" command on that
>>> platform? Also, what is the version of Qt5 that you are using?
>>>
>>> The reason these details are important is I cannot replicate the text
>>> alignment issues you demonstrated with pdfqt and pngqt results for
>>> example one on your platform. My platform is Debian Buster (with the
>>> Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7
>>> 1700). I demonstrated that I cannot replicate your badly aligned
>>> results by configuring cmake in the way I described above and then
>>> executing the following commands:
>>>
>>> # Build the prerequisites for the specific examples below
>>> make -j16 test_c_pngqt
>>> make -j16 test_c_pdfqt
>>>
>>> # Build two specific examples
>>> examples/c/x01c -dev pngqt -o test.pngqt
>>> examples/c/x01c -dev pdfqt -o test.pdfqt
>>>
>>> I have attached those two result files so you can see for yourself that
>>> there are no text
>>> alignment issues.
>>>
>>> Also your suggested changes to plqt.cpp likely conflate two issues. (i)
>>> alignment issues caused
>>> by your platform and not PLplot, and (ii) the size of the resulting
>>> characters (which I
>>> would prefer to put off discussing until later). So to check those are
>>> two separate issues,
>>> what happens if you restore plqt.cpp to its original form except for
>>> this one line change:
>>>
>>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
>>> ==>
>>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 1;
>>>
>>> ? I am pretty sure that is the equivalent of the first part of your
>>> change where you
>>> are forcing the vectorize part of the code to be executed.
>>>
>>> If that one-line change is all you need to bypass your Qt5 platform
>>> issues, then I would be willing to test that simple change here to see
>>> if it also works on my platform. But the vectorize = 1 code path has
>>> not been tested by anybody but you over the years and is just likely a
>>> workaround for your Qt5 platform issue so I likely won't push that
>>> one-line change in general.
>>>
>>> Also you do appear to be having text alignment troubles consistently
>>> over the years with your (opensuse?) Qt5 platforms so perhaps it is
>>> time to try other Qt5 platforms? For example, you could build the
>>> upstream version of Qt5 yourself. The very early versions of Qt5 did
>>> have character alignment difficulties in that upstream version, but my
>>> experiments showed they solved the alignment issues important to
>>> PLplot by 5.3.x so you will likely find the latest upstream Qt5 also
>>> does not have text alignment issues. And if that is the case, then
>>> that experiment should be the basis of a bug report to your
>>> distribution. Of course, if that bug report gets no response another
>>> possibility is to try Debian (which I know works well now with Qt5)
>>> some Debian derivative such as Ubuntu or Mint or some other rpm-based
>>> distribution such as Fedora.
>>>
>>> Good luck, and let me know how it goes.
>>>
>>> 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
>>> __________________________
>>
>>
>>
>> --
>>
>> António Rodrigues Tomé
>> Universidade da Beira Interior
>> Instituto D. Luís (lab associado)
>> email address:
>> ar...@gm...
>> ar...@ub...
>> http://www.researcherid.com/rid/A-5681-2013
>>
>>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>
--
António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013
|