Hi Werner:
Most of this is directed to you but there is also a request for Hazen and
Jerry at the end.
On 2009-08-31 08:27+0200 Werner Smekal wrote:
> Hi Alan,
>
> weekend is family time, so no work from my side on this issue here.
Understood. We are all volunteers here with limited (and variable) spare
time so we should all expect that responses to questions on this list are
sometimes delayed.
> I just
> updated to the last plplot version and I get now little different warnings.
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0
> 1.0 1.0 1.0 1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.
> 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0
> 0.0 0.0 0.0 1.0 0
>
>> By the way, I am pretty sure (unless a device driver is really screwed up)
>> that cmap1 palette reading troubles should be device independent. Could you
>> confirm that by trying -dev psc for example 16?
>
> Nope, this warnings only occur with the qt devices. All other drivers I tried
> (wxwidgets, xwin, ps, pdf) worked as expected.
That is a really strange result.
The relevant code from plctrl.c (subject to line rewrap) is identified
exactly by the unique error message above.
fgets(color_info, 160, fp);
if (sscanf(color_info, "%lf %lf %lf %lf %lf %d",
&pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) {
snprintf(msgbuf,1024,
"Unrecognized cmap1 format (wrong number of items for version 2 of format)
%s\n",
color_info);
So the above warning message outputs exactly the color_info which sscanf
cannot interpret properly. But if we look at the data in that warning
message above it is perfect; five floating point variables in a row, then an
integer just like the above sscanf format directives and corresponding
pointers. In particular, we already know there is no hidden null characters
embedded in the middle of color_info because then that would affect the
output of color_info in an obvious way (truncated early). It is hard to
tell from e-mail, but I suppose there could be a line ending or other
non-printing characters embedded in the middle of color_info.
Just to be sure that is not the case, could you run example 16 again and
capture the warning message directly into a file (using ">&" and not cut and
paste to make this test as direct as possible), then analyze that file with
something like od to see whether there are any non-printing characters in
color_info? This is improbable (since color_info is read immediately before
in the code with fgets above), but it would be good to have rock-solid
confirmation that this improbability is not true.
If you confirm the color_info output is perfect yet sscanf cannot read it,
this is a second very strange result (after the very strange result that the
problem only occurs for qt devices).
The third very strange result is that the 3rd message above corresponds to
cmap1_gray.pal which is read without issues for the first page of the same
example 16!
One hypothesis that might explain (more or less) all three strange results
is that dynamic loading of qt devices is linking in a Qt4 library that
breaks sscanf (or fgets if color_info turns out to have some embedded
non-printing characters) on your system in some way. I know that hypothesis
is quite speculative/improbable so if somebody here can come up with some
more probable hypothesis to explain these strange results, please speak up.
Werner: here are the next steps I would appreciate you doing to help figure
this out.
* Check color_info by directly capturing the above error message into a file
and binary dump that file with something like the od application to make
sure there are no non-printing characters embedded in the middle of
color_info. (I have done that already with this e-mail, and the color_info
output above was clean of embedded characters, but some of the applications
used in the long e-mail chain between us could have filtered out those
non-printing characters, and the right way to do this is by immediate file
capture on the platform where the warning message is generated.)
* Experiment with different Qt4 versions to see if the problem goes away
for one of them.
Hazen and Jerry: would you do similar experimentation (running example 16
with a number of different Qt4 versions) to see if you can replicate the
issue that Werner found? To switch from one Qt4 version to another, simply
put the appropriate qmake on your path before a fresh build and cmake does
the rest.
If by such experiments from Werner, Hazen, and Jerry we establish that the
cmap1 palette file reading problems for example 16 occurs only for one Qt4
version on OS X but not others, then we only have to warn about that bad Qt4
version for OS X in the release notes, and we are (finally) done with this
issue.
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
__________________________
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
