Hi Hazen and Andrew (Roach): This is a long post because it represents a lot of testing work. If you don't want to absorb it all at once, please at least look for "Hazen" or "Andrew" below for specific questions addressed to you.
I have been doing a comprehensive comparison of png and pngcairo results (99 [!] pages of them) generated by ./plplot-test.sh --device=png --front-end=c and ./plplot-test.sh --device=pngcairo --front-end=c for the installed and built C examples) to check whether there are any showstoppers for my goal of replacing png by pngcairo examples on our web page. This is for an internally modified plplot-test.sh script that uses the same -geometry option for png and pngcairo so that the results have the same scale. That change makes it really easy to click between the png and pngcairo results for a given page and spot all the differences. Here is the list of differences that I have spotted so far with "Worse", "Better", or "Same" comment meaning pngcairo is worse than, better than, or the same as png with regard to the issue that is mentioned. (Worse) graphics antialiasing is better implemented for png than it is for pngcairo. The -drvopt smoothlines=1 option for -dev png gives smooth looking drawn lines without messing with the filled areas. The -drvopt graphics_anti_aliasing=[023] options (corresponding to three of the four different kinds of antialiasing hints allowed with libcairo graphics objects with the graphics_anti_aliasing=1 option reserved for no antialiasing) for -dev pngcairo also gives smooth lines, but messes with the filled areas introducing artifacts such as the thin horizontal and vertical black lines for example 16 (due, I presume, to the black background leaking through transparent areas caused by the antialiasing of filled areas). I have tried no antialiasing of graphics objects (i.e., -drvopt graphics_anti_aliasing=1) for example 16, and that gets rid of the artifacts. However, if that option is tried on other examples, jagged drawn lines result. I don't see this failure of libcairo to distinguish between lines and fills for antialiasing being fixed any time soon. Assuming we are stuck with this limitation for the foreseeable future, than probably the best thing to do here (assuming we decide to go with pngcairo for our website examples) is to adjust the generating script so that -drvopt graphics_anti_aliasing=1 is used for example 16 (and example 20). For all other examples we should use the default full graphics antialiasing (-drvopt graphics_anti_aliasing=0). N.B. 1 and 0 have the opposite to expected meanings here because we are using the same order as for the cairo_antialias_t enumeration given at http://cairographics.org/manual/cairo-cairo-t.html#cairo-antialias-t which has CAIRO_ANTIALIAS_NONE in the second place rather than in the more natural first place. (Worse) For example 1 the circle symbols in pngcairo are slightly displaced (lower) than the line. This does not happen for pscairo or xcairo (or png). Hazen, can you confirm this difference between pngcairo and other cairo devices for your platform? I strongly suspect this small misalignment is an issue in the cairo png back end. (Worse) For all example with "st" in the text (e.g., example 16 on the first page), there is a minor rendering issue between the "s" and "t". This rendering issue does not appear for xcairo or pscairo so I strongly suspect this is a cairo png back end rendering issue. (Same) clipping does not work by default for pngcairo but does for png. However, the -dev pngcairo -drvopt text_clipping=1 option solves that. If we decide to to move to -dev pngcairo for the website examples, we should change the script that generates the examples to use this driver option. (Same) Some png and pngcairo examples (especially example 3 and example 13) have large black margins around them. In general, the margins should be trimmed to the area which was actually used for the graphics + text such as occurs for -dev psttfc and -dev psc (for Hershey fonts). (I have been discussing with Hazen off-list the possibilities for implementing the option of cropping the unused margins of cairo results, but there doesn't seem to be any obvious way to do this with libcairo. I do have a question about this posted to the cairo mailing list, and if they come up with something that we are able to implement, then this issue will be reclassified from "Same" to "Better".) (Better) For the cairo devices, fontconfig selects the font from the generic list presented within the code (if the user does not override at run time by setting environment variables). Here are the five font family possibilities that fontconfig is currently allowed to choose from: "Arial,Bitstream-Vera-Sans,sans", "Times-Roman,Bitstream-Vera-Serif,serif", "Courier,Bitstream-Vera-Sans-Mono,monospace", "Arial,Bitstream-Vera-Sans,sans,serif", "Arial,Bitstream-Vera-Sans,sans,serif" fontconfig is quite flexible. It takes these font hints (in decreasing order of precedence with the generic sans and serif allowing it to use its own precedence order for that super family of fonts) until it finds a font that will deliver the desired glyph for the family, style, and weight given by the FCI (PLplot font characterization integer) specified for the unicode glyph being rendered. In contrast png uses the plfreetype approach which currently does not use fontconfig so it must be quite specific about its fonts. There are 30 such fonts to cover all the possibilities (five families [sans, serif, mono, script, and symbol], 3 styles [upright, italic, oblique], and 2 weights [medium and bold]). The 30 font names are configured at cmake time, and you can also specify environment variables to change any of the 30 fonts during run time. With this approach you have control of fonts in excruciating detail before the application starts, but it is a real pain to use this system if you ever want something different than the default fonts (see the instructions for example 24), and you cannot change the font representing say the combination sans, upright, and medium half way through the plot to accommodate a glyph that might be missing. In contrast, fontconfig is designed to make font choice easy, and within the font hints that you set it exhaustively attempts to find a font that has the desired glyph. To summarize the fontconfig (and therefore pngcairo) advantages, fontconfig goes all out at run time to find a font with the requested glyph, there is nothing to configure for fonts at cmake time (i.e., the above hints are usually fine so they can be embedded in code rather than configured), and only five environment variables (not 30) need to be used at run time in those rare circumstances where you might want to change from the above hints to fontconfig about what font families to use for the five possible PLplot font families. The result of the first advantage is our pngcairo examples have fewer missing glyphs than our png examples, see especially examples 6, 7, and 23 which exercise a wide range of different glyphs. Also for example 24 (the rainbow "Peace" flag) you don't have to do anything special to get a good-looking pngcairo result, while for png you need to set environment variables to get a decent looking result. (Better) pngcairo has perfectly aligned text (e.g., as written by plmtex as opposed to the misalignment problem noted above for symbols which are rendered via plpoin) while png does not. For example, png is systematically down and slightly to the left of center for all the numbers in the second page of example 2. For unknown reasons, this png problem doesn't show up consistently. For example, the shift is apparent for the tick labels in example 4 and the placement of the "-20 dB/decade" string for that example, but I cannot see any misalignment problem in the tick labels of example 5 png results. (Better) There is a bug in -dev png that shows up for the second and subsequent pages of some plots. See e.g., http://plplot.sourceforge.net/examples-data/demo09/x09.02.png where the box line disappears and the numbers get blurry or http://plplot.sourceforge.net/examples-data/demo19/x19.02.png where all lines completely disappear! I believe we have seen and fixed this bug before, but somehow it is back now. Andrew, could you look into this please? (Better) libcairo correctly renders complex text layout (CTL) languages such as Thai (both vertical and horizontal positioning required), Hindi (mostly left-to-right, but some right-to-left), Arabic (right-to-left), and Hebrew (right-to-left). This is currently not the case for plfreetype (which png uses) which does simple left-to-right rendering which makes a mess of CTL languages. For this reason we had to do something special (use -dev psttfc) before for our website example 24 results, but all these complications go away if we use pngcairo. To summarize all these comparisons, it appears that the pngcairo device has matured, and currently it is more bug free than the png device. It does appear that the underlying cairo library png back end still needs some maturation (consider the small misalignment and "st" rendering issue discussed above), but I believe that is only a matter of time, and, in any case, these issues are small enough so they should not embarrass us on the website. The only substantial libcairo issue that showed up in the comparison with png is the antialiasing for graphical objects does not distinguish between lines and filled areas, but I have suggested a workaround above for that case. So the pngcairo negatives are small (and probably short term) or can be worked around, or png has the same issue (results plotted with unused margins). Currently there are some bugs for png noted above. Furthermore, the use of fontconfig and the correct rendering of CTL languages are both big positives for -dev pngcairo. Thus, I recommend we adopt pngcairo results for our web examples from now on. If there are no strong objections to this change, then, Hazen, we should consult about updating the script that you run for each release that (re-)populates the web site examples. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
