On 2017-08-21 06:53-0000 Arjen Markus wrote:
I have uploaded the full contents of the examples directory, as you requested.
I downloaded those plot results for the MinGW-w64/MSYS2 platform
successfully, and evaluated them for rendering issues.
The conclusion is that in the vast majority of cases, plot rendering
is fine on this platform so we can highly recommend this platform to
our Windows users. However, there are a few exceptions to this good
rendering conclusion that are discussed in detail below, but none of
these issues are release critical. Thus, the "NOTE:" remarks below
correspond to what I think we can do to fix some of these issues after
5.13.0 is released.
A. UTF-8 (i.e., human-readable format) results:
Here are the types of UTF-8 files and formats we are contending with
software@raven> file $(ls x00c* |grep -v txt) |grep -Ei 'postscript|svg|xfig'
x00c.ps: PostScript document text conforming DSC level 2.0, type EPS
x00c.psc: PostScript document text conforming DSC level 2.0, type EPS
x00c.pscairo: PostScript document text conforming DSC level 3.0, Level 2
x00c01.epscairo: PostScript document text conforming DSC level 3.0, type EPS,
Level 2
x00c01.epsqt: PostScript document text conforming DSC level 1.0
x00c01.svg: SVG Scalable Vector Graphics image
x00c01.svgcairo: SVG Scalable Vector Graphics image
x00c01.svgqt: SVG Scalable Vector Graphics image
x00c01.xfig: FIG image text, version 3.2, ASCII text, with very long lines
x00cxx.psc: PostScript document text conforming DSC level 2.0, type EPS
I. Some of these UTF-8 results can be differenced with corresponding
Linux (Debian Jessie) results with few or any adjustments. This
allows us to avoid having to look for rendering issues with these
particular device results).
For such comparisons I usually did some variation on the command below
where files in the present directory correspond to MinGW-w64/MSYS2
platform results and files in ${DIR} correspond to Debian Jessie
results. N is a string that corresponds to "00" through "33" (with
"32" skipped. The ls command
and grep -v command selects a certain subset of the
results (in this case, just selects the ps device driver results).
The -i 172 option for the cmp command ignores the date stamp in the
comparison.
for N in $(seq --format='%02.0f' 0 33|grep -vE '32'); do
echo "Examples $N"
for FILE in $(ls x${N}*.ps|grep -v txt); do
echo $FILE
cmp -i 172 $FILE "${DIR}/$FILE"
done
done
__________________________________________________________________________________
1. The ps device results from the C standard examples were identical to the
corresponding Linux results.
2. The xfig device results from the C standard examples were identical to the
corresponding Linux results.
__________________________________________________________________________________
3. Your report tarball already shows that psc results for all the
bindings currently enabled for MinGW-w64/MSYS2 (i.e., c++, fortran, lua,
python, and tcl) are identical with the corresponding c results with
the exception of
lua
Missing examples :
Differing graphical output : 14a 19 23
Missing stdout :
Differing stdout : 31
A variation of the above "for N ..." set of commands showed all psc
device results from all examples were identical to the corresponding
Linux results except for the above Lua examples. So the only Lua
differences we should be concerned about (post-release) are those in
the above summary.
As I believe you have already remarked, detailed diffs corresponding
to the above Lua examples show many trailing ".0" differences such as
-0.150 (0.0) SW
+0.150 (0) SW
NOTE: Apparently some Lua version difference is able to
affect whether trailing zeros are eliminated
by the -dev psc implementation that is written in C.
Actually, in the interest of saving space, the above line
should read
.15 (0) SW
so this is fundamentally a -dev psc formatting issue that we need to look at.
In addition when the above trailing zero issues were suppressed using
sed there are "real" differences
such as insertion of the following text in the Linux
version of these PostScript files:
+0.150 (0) SW
+(0) show
The trailing zero diffences have to be eliminated first before
we can look at the cause of the remaining "real" differences,
but that cause is likely to be due to some Lua version difference
between our two platforms. So I may run into this same issue
once I update to Debian Stretch (which has a newer version of lua).
The above stdout differences (as opposed to the psc differences) are due to a trailing
".0" on some
of the numbers being output, but this is directly from Lua rather
than indirectly via -dev psc so it should be an entirely different
issue.
NOTE: I am pretty sure the cure for this lua stdout issue will be to specify
exactly the same
stdout format in Lua and C standard examples 31 rather than default
format (which appears to have changed between our two Lua versions).
__________________________________________________________________________________
4. The svg device results from the C standard examples were identical to the
corresponding Linux results except that quantities formatted with an
"e" exponent had a leading 0 in the exponent. e.g.,
- stroke-width="1.000000e+000"
+ stroke-width="1.000000e+00"
(i.e., if I adjusted one exponential form to the other using sed, there were
no differences left for all our standard examples).
NOTE: to address this issue we have to use explicit exponent
formatting in the -dev svg C implementation rather than the default used
by gcc (which apparently changes between the two gcc versions being
compared here). This change should also protect us when
comparing between old and new gcc results on the same machine.
__________________________________________________________________________________
II. These remaining UTF-8 results have for unknown reasons large (and
therefore useless for further analysis) differences with the
corresponding Linux (Debian Jessie) results. In all these cases I
fell back to the "display" method of visually looking for rendering
issues (see below).
1. The svgqt and svgcairo devices used different system fonts and also appeared
to use different SVG methods of scaling the results.
2. For the pscairo and epscairo results, "diff" showed
different fonts were used for the two platforms and also there were limited, but
still significant PostScript command differences.
3. For the epsqt device, "diff" showed different fonts were used for
the two platforms and also there were limited, but still significant
PostScript command differences. One of those differences was the
bounding box for the MinGW-w64/MSYS2 result had X and Y limits swapped in error
(likely due to a Qt4 bug on the Windows platform).
B. Binary (i.e., non-UTF-8 format) results:
Here are the types of binary files and formats we are contending with
software@raven> file $(ls x00c* |grep -v txt) |grep -Eiv 'postscript|svg|xfig'
x00c.pdf: PDF document, version 1.3
x00c.pdfcairo: PDF document, version 1.5
x00c01.bmpqt: PC bitmap, Windows 3.x format, 842 x 595 x 24
x00c01.jpgqt: JPEG image data, JFIF standard 1.01, resolution (DPI), density
72x72, segment length 16, baseline, precision 8, 842x595, frames 3
x00c01.pdfqt: PDF document, version 1.4
x00c01.pngcairo: PNG image data, 720 x 540, 8-bit/color RGB, non-interlaced
x00c01.pngqt: PNG image data, 842 x 595, 8-bit/color RGB, non-interlaced
x00c01.ppmqt: Netpbm PPM "rawbits" image data, size = 842 x 595
x00c01.tiffqt: TIFF image data, little-endian
I. Binary files that are identical between the two platforms:
The appropriate variant of the above nested for loop commands shows
the *.pdf files are identical between the two platforms.
II. Binary files that are different between the two platforms:
diff x00c.pdfcairo "$DIR"
generates the message
Binary files x00c.pdfcairo and .... differ
and similarly for the remaining files in the above list other than
x00c.pdf. In all these cases I fell back to the "display" method of
visually looking for rendering issues (see below).
C. The "display" method of visually looking for rendering issues.
I looked at all binary results that had differences between the
two platform and all UTF-8 results that had *major* differences
between the two platform as follows:
for N in $(seq --format='%02.0f' 0 31); do
echo "Examples $N"
for FILE in $(ls x${N}*|grep -vE '|grep -vE '(txt|ps|psc|xfig|pdf|svg)$'); do
echo $FILE
display $FILE
done
done
I also did some displaying by hand of a sample of the x33 results.
The following were the MinGW-w64/MSYS2 rendering issues worth
mentioning that did not occur for the Linux case:
* As expected from the bounding box issue reported above, all epsqt
results had parts of the plot missing.
* A similar issue occurs for pdfqt.
* All cairo devices had character sizes on the MinGW-w64/MSYS2
platform that were ~50 per cent larger than the corresponding Linux
results, but such was not the case for the qt devices.
* Example 23 shows a relatively small number of missing glyphs in the
system fonts you have access to with MinGW-w64/MSYS2 for all the
cairo and qt devices. (As opposed to the Linux case where system
fonts provide complete glyph coverage for example 23 for all cairo
and qt devices.) I looked at the package names for MinGW-w64/MSYS2
and the only package name with "font" in it is font-config. So I am
virtually positive that MinGW-w64/MSYS2 has chosen at this time
(although it is possible later on they will provide all or part of
the official fonts that are available to Linux users) to use just
the same official system fonts that are accessible for "bare" Windows
on your computer.
If you haven't done so already, I would consult with the system guys
in your company to make sure that you have all possible official
system fonts installed on your computer. However, I would recommend
against installing unofficial Windows fonts to give you more unicode
glyph coverage because my prejudice is there is likely to be more
security and reliability issues with such unofficial software
packages.
* The Arabic and Hebrew glyphs are missing from example 24 for all the
cairo devices. But this is not a system font issue because those
glyphs are all available for the qt devices.
To summarize, I have evaluated rendering issues for the
MinGW-w64/MSYS2 platform using all pages of your results of all our
standard examples (except for standard example 33 where I only sampled
the 100 pages of that example) of all our noninteractive devices that
you have been able to enable on this platform. Three rendering issues
have been labelled above with "NOTE:" where I believe there is a
PLplot issues we can do something about after the 5.13.0 release. The
rest of the rendering issues I noticed are discussed above, but in all
those cases I believe the issue is with external libraries on this
platform and not issues with PLplot.
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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
