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 |