On 2015-11-27 12:00-0800 Alan W. Irwin wrote: > The conclusion is there is a specific bug for the ps device > driver for PostScript fonts, and also a specific bug for the svg device > (which is probably not related). I will look into both of those.
Hi Peter (again): I am moving this further discussion from plplot-devel to plplot-general since the general advice I give below is more appropriate for the PLplot users that typically subscribe to that mailing list. The issue with the svg device turned out to nothing to do with PLplot. With svg you can look at the xml file to verify everything is entered correctly. The relevant xml code is <tspan font-family="sans-serif" font-style="normal" font-weight="normal">Hershey code ▶</tspan> If you translate each of those unicode characters, e.g., with the handy gucharmap application that is available on Linux, they spell out "Hershey code " followed by the unicode character for an arrowhead symbol. That is the expected result for that modified example. However, when my svg ImageMagick "display" viewer renders that result it drops the blanks and also replaces the last unicode character by "?". So that is an issue with Debian Jessie display command that never occurred for Debian wheezy. I then shifted to using a browswer to view that result and both the konqueror and iceweasel (a.k.a. firefox browser) rendered that svg file correctly with blanks and arrowhead rendered correctly. So try -dev svg and check the resulting file to see whether x25b6 shows up in that file as it should do, then use your best SVG viewer (probably a browser) to see if that gives you good rendering results on your own platform. I have dug a lot deeper now for the missing arrowhead issue of -dev psc. See my recent commit message (especially the last few sentences) at <http://sourceforge.net/p/plplot/plplot/ci/6a6241e918cd05e2cd20a02011bb33ac7ba62468/>. My (almost certain) conclusion is the issue is the standard set of 35 Type 1 Adobe fonts do not include such a glyph. When I compiled the C table that correlates unicode and type 1 indices and which therefore controls what Type 1 glyph is rendered for a particular unicode index, I did that task in a systematic way (although I have forgotten exactly which basic resource I used to set it up), but I ran into this issue a lot. Basically, type 1 fonts just suck in terms of having more than a minimal number of glyphs available. As I recall the limit is 255 for a given font file and those 35 standard font files are typically for sans, serif, bold, etc., variations. Thus a large percentage of the 255 slots for each of those files are already taken up with lower- and upper-case Latin and Greek characters so that leaves very few slots to represent more than Latin and Greek. Thus, the arrow head could not be represented for the standard set of 35 type 1 fonts and the ps device driver that uses those fonts. Given this limitation of -dev psc, I suggest you use -dev svg or better yet install one of the big suites of open-source graphics libraries that are available for Windows (either the GTK+ suite of libraries or else the Qt4 (or Qt5) suite of libraries). You can install those libraries by hand on bare Windows, but a much more convenient and safe option (in terms of ABI compatibility) is to use a Windows distribution of free software such as Cygwin or MinGW-w64/MSYS2 where installation of the GTK+ or Qt4 suite of libraries is extremely convenient, and a consistent ABI is guaranteed (everything compiled with exactly the same compiler version) on those distributions. You get no such consistent ABI guarantee for bare Windows since an arbitrary download of some binary version of the GTK+ suite can be compiled with any compiler and similarly for an arbitrary binary download of the Qt4 or Qt5 suite of libraries. MinGW-w64/MSYS2 is quite a new distribution of free software for Windows, but it already is almost as complete as Cygwin, the libraries it supplies (unlike the Cygwin ones) are native Windows libraries (i.e., they do not link to some additional dll such as cygwin.dll), it has exponentially growing popularity, and Greg already has obtained excellent comprehensive PLplot test results for that platform. To get access to MinGW-w64/MSYS2 you should start by reading <http://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/>. Once those graphics libraries are installed, then PLplot allows you to build either/both the "cairo" device driver which implements many different devices include PostScript and PDF ones and which depends on the pango/cairo subset of GTK+ or the "qt" device driver which also implements many different devices including PostScript and PDF ones and which depends on either the Qt4 or Qt5 suite of libraries (note the latter case is still experimental and requires you use the -DPLPLOT_USE_QT5=ON CMake option which normally defaults to OFF). For both the cairo and qt cases, the resulting PostScript and/or PDF results use TrueType system fonts (installed as a bunch of drawing instructions in the file header) rather than Type 1 fonts. There is no 255 limit on the number of glyphs in a TrueType font file so they tend to have an extensive glyph coverage. Finally, the TrueType font results look really good (compared to, say, Hershey font results). (See <http://plplot.sourceforge.net/examples.php> for how our standard examples look with cairo devices, and the corresponding qt device driver results similarly look good.) I hope this discussion of the limitations of the ps device driver makes sense, and I also hope this discussion helps you and other Windows users to start taking advantage of the high quality (both in terms of glyph coverage and the beauty of the rendered text results) cairo and qt device drivers. 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-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
