Hi Alan,
>
> 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.
I think I found out what the problem is. The first page reads okay,
but then qt takes over to show the plot and somehow changes the locale
or something. This is on a Mac, English version, but Austrian locale -
so after that scanf expects floating point numbers to be written
numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I
assume that this is the problem, since I printed the out the numbers
with printf in case sscanf fails and the output is:
0: 0.0 0.0 0.0 0.0 1.0 0
1: 1.0 1.0 1.0 1.0 1.0 0
0: 0.0 1.0 1.0 1.0 1.0 0
0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440
*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items (1) for version 2 of
format) 0.0 1.0 1.0 1.0 1.0 0
I'll try now to play around with my locale. The other Mac has also
Austrian locale, but obviously Qt cocoa doesn't mess around here.
I'll keep you informed.
Regards,
Werner
>
> 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
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: sme...@iap.tuwien.ac.at
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
------------------------------------------------------------------------------
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
