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