On 2014-03-31 17:11-0700 Alan W. Irwin wrote: > [The only Qt5] rendering issue I spotted is all text appears > to be vertically offset by ~half a character height compared to qt > device driver results with Qt4 and also cairo device driver results. > > Do you confirm that offset with your system version of Qt5? > > For some reason, there always seems to be arbitrary vertical offsets > we have to apply for text rendering and those offsets are different > for each major external library dependency such as Qt5 (or pango/cairo > or Qt4). > > Fixing that issue (without destroying the good vertical offset for > text we already have for the Qt4 version of qt) is next on my agenda.
Done as of revision 13091. The text rendering now looks a lot better in the epa_built Qt5 case, but there are some minor caveats. For details about those, see the commit message. @Andrew: IMPORTANT do you confirm reasonable looking vertical text alignment for this revision and your system version of Qt5? As part of this empirical vertical text alignment work, I completely rewrote examples/python/test_circle.py (as of revision 13092) to demonstrate any remaining vertical offset issues for many additional UTF-8 glyphs beyond what was done before for the UTF-8 "large circle", "box drawings light diagonal cross", "asterisk operator", and "ordinary asterisk" glyphs. My first discovery from these results (which I should have figured out from the old version of this example but did not) is that the ordinary asterisk is a very poor symbol to use for plotting points since font designers apparently have a long artistic tradition of centering this particular symbol substantially above the centre of the character box. Replacing the ascii asterisk symbol, "*" used in standard examples 4, 26 and 33 with "#(728)" (which for both Hershey and Unicode fonts translates to an asterisk operator glyph which has far superior vertical alignment) gives much better looking results for those standard examples. I have already done this change for C and Python locally and making the remaining example changes consistently for all languages and commiting all these example changes is next on my agenda. The second discovery is that the Qt4, pango/cairo, and Qt5 libraries all configure fontconfig differently to obtain the "best" system font to render the requested unicode glyph. The evidence for this is a variety of glyph sizes and shapes for the three different cases as well as occasional (i.e., the Korean glyphs in example 24) missing glyphs in the Qt5 case which are not missing for the other two cases. Note, that test_circle.py is extraorinarily sensitive to vertical alignment issues; e.g., a vertical offset of 0.01 of the character height can (just) be detected. So assuming the different font sets have different artistic impressions of the correct vertical alignment within the character box, you expect the slightly different vertical alignment results in the three different cases that I have observed with test_circle.py. Given that caveat, the "artistic" variations in vertical alignment are fairly small between the various fonts chosen in the three different cases. Furthermore, the dispersion in vertical alignment between the various UTF-8 characters is smallest for our qt device driver (using Qt4), next smallest for our cairo device, and largest (but still probably acceptable) for our qt device driver (using Qt5). The first two dispersion results were obtained with no mean empirical offset in vertical text position, but the latter result was derived using a substantial (more than half a character height) empirical offset that best aligned the "box drawings light diagonal cross" glyph. Presumably, whenever the Qt5 issues with font selection and vertical alignment of characters are fixed so that there is consistency with the same results for Qt4, that empirical offset will have to be replaced by zero, but revision 13091 should be good enough for now with epa_built Qt5.2.1 (and also system versions of Qt5.2.x if Andrew confirms the vertical alignment is OK for his Qt5.2.x version). Other Qt5 issues I have mentioned before are the following: 1. pyqt4 is disabled. I don't have any sip or pyqt expertise so we need a volunteer to look at this for the Qt5 case. 2. All Qt5 tests have so far only been done in the build tree for the shared library/dynamic devices case. Thus, our usual comprehensive testing will likely reveal more Qt5 build-system issues that I plan to deal with as second on my current agenda after the examples changes mentioned above. In addition, if I recall correctly there were a lot of difficulties with font selection and the vertical alignment of text with early versions of Qt4.x before it finally settled down, and it looks like Qt5 (which is also in an early development stage) currently has these issues as well. Thus, because of these Qt5 issues (and also because of the two PLplot issues above) I am going to continue to label the -DPLPLOT_USE_QT5=ON cmake option as experimental and leave it OFF by default. However, this option continues to improve (i.e., with the present vertical alignment workaround for Qt5 vertical alignment issues) so I encourage those here to test this option either with a system version of Qt5 (if available) or an epa_built version of Qt5. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
