Alan W. Irwin writes:
> I have just been trying some consistency tests with plrender which it
> completely fails.
> Not only are the two files different lengths, but they render substantially
> differently: (one uses an obviously different spacing for the dashed line
> grid in the 4th plot, and there are lots of other visual differences as
This is an example of a consequence of the mm versus virtual coords issue
that Maurice mentioned.
> plrender test.plmeta -dev plmeta -o test1.plmeta
> ls -l test*.plmeta
> -rw-r--r-- 1 software software 31707 Jan 28 20:15 test.plmeta
> -rw-r--r-- 1 software software 30504 Jan 28 20:21 test1.plmeta
> test.plmeta and test1.plmeta should be exactly the same, but they are not.
Oh gosh, where to begin?
> Maurice and Geoffrey, do you have any idea why plrender seems to have these
> inconsistencies? I have never tried such consistency checks before so this
> may be a long-standing problem rather than something recently introduced.
Yes, as Maurice explained briefly, it is a long standing issue, with us since
the absolute beginning. I was young and inexperienced then, and more
importantly, killing time on the French Riviera since the French government
wouldn't allow me to have a job. Now I'm older and wiser, and have waaaaay
less free time on my hands.
I have thought about PLplot development projects in this area on many
occasions over the years. Probably if I were doing a metafile facility from
scratch today, I might not do it the same way. To put it in mathematical
language, a metafile should be an eigenstate. That is, rendering a metafile
to a metafile should change *ABSOLUTELY NOTHING*. Well, that's definitely
not how the existing system operates.
To some extent, we have solved this in our simulation codes by making the
true state of the data be in a data-state-dump-file outside of PLplot. So,
rather than rendering a metafile to a new device, we now just load the same
original data back into the plotting tool, and regenerate the plot. But
that's more recent. Before getting all sophisticated with application-state
files, we did use to just render to plmeta, and then rerender to physical
devices N times, as Maurice mentioned.
I guess if I were giving advice to a PLplot application developer, I'd
currently recommend application-specific-state-files as a commendable
But as a PLplot developer, I have to agree, metafiles need a mondo-makeover.
From the standpoint of personal priorities, I guess the metafile makeover
rates lower on my priority list than investment in fidelity, contouring algs,
shading work, perspective plots, raster image support, back drops,
translucency, overlay widgets, the ***infernal*** redisplay nits, scalable
zooming, linker decoupling, an elisp binding, or background music.
But, in the grand scheme of things, an eigenstate metafile would be a good
One thought I've had over the years, is that it might be good to have the
metafile stand at a wholly different level than its current fixation with
virtual coords. Instead of a few primitives plus virtual coords, a
completely alternative metafile formulation would be to capture the data
passed into the PLplot API, significantly, *before any graphical
transformations*, and store the data in the metafile as a tuple of A) a token
to represent the PLplot API entry point called, and B) the supplied data. If
this were what were stored in the metafile, then the metafile renderer could
regenerate the /exact/ same viewing experience, by reconstituting the exact
same API calls with the exact same data. And then any device could be
selected, and if the plmeta device were chosen, it would again capture the
same API calls with the same data, and metafiles rendered to metafiles would
be bitwise identical. This is essentially how I think today, that it should
But anyone with even a brief exposure to the existing PLplot implementation,
can surely see that this is a massive project, which would require massive
restructuring of the whole core/driver architecture.
Geoffrey Furnish Lightspeed Semiconductor Corp
voice: 512-402-9016 11612 Bee Cave Road, Suite 130
fax: 512-402-9643 Austin, Texas 78738
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
- Brian W. Kernighan