Re: [Plplot-devel] New test run on Debian woody + FURTHER TESTS + NEW RELEASE?

[Alan W. I. <ir...@be...>]

On Thu, 25 Oct 2001, Joao Cardoso wrote:

> On Thursday 18 October 2001 18:14, Alan W. Irwin wrote:
> | On Thu, 18 Oct 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
> | > On Thursday 18 October 2001 01:32, Alan W. Irwin wrote:
> ...
>
> | FURTHER TESTS....
> |
> | I also ran the script for the png driver this morning, and there are so=
me
> | problems (for real this time ....;-)) with the octave stuff in that cas=
e.
> | There are severe size problems with the legends for all plots.
>
> As it didn't happen for me, I was assuming that the fault was yours.

Note my comment was for the png driver only.  Not the postscript one. Do yo=
u
really have a clean checkout of latest CVS with no local changes? If you
cannot confirm the octave legend problem for png, then that is really
strange because it is quite obvious on my system for a clean checkout (i.e.=
,
"mv plplot plplot_old; cvs checkout plplot").  I cannot remember very well,
but I think this png driver legend problem for all the octave examples has
been there from the first day I tested it long ago (probably even before I
did the aspect ratio stuff), but to be sure we would have to review my old
e-mail to you.

> But the other day I start octave with the xwin driver, and I noticed the
> problems.

> ....Hummm, can't this be related with your changes related with the aspec=
t-ratio
> problem?

I doubt it.  My changes prior to 5.0.4 should have no effect unless you are
reorienting (-ori option with -freeaspect) or changing the overall aspect
ratio (-a option). The -portrait option is also available for the postscrip=
t
driver, but I assume you are not using that.  All these character aspect
ratio changes are central to plplot and have nothing to do with individual
drivers (except the simple -portrait option which is available as a
convenience for the ps driver, but which just combines other options that
are implemented centrally and not in the individual drivers.)

I noticed that the legend problem was much less severe for ps as well. Your
legend placements should look identical for all drivers, and they don't.
From=20the overall plotting perspective the only real difference between
drivers is their pixel units, but I don't think you should be using those
unless you scale them to the pixel size of the plotting area, for example.
If you did that you would know a character height is some fraction of the
plotting area, and your results would be identical regardless of the number
of pixels assigned by each driver to the plotting area and to the
character area.

>
> |  This does
> | not happen for the postscript results although the sizing of the legend=
s
> | needs work there as well.  I think the problem is that pixel units are
> | being used rather than coordinates that will give the same result for e=
very
> | driver.
>
> The problem with the legend box, is that I need to calculated the box
> dimension, knowing the string size and the number of lines, and I use the
> returned height from plgchr(). As plplot fonts are proportional, the widt=
h of
> the box will be wrong some times, but the height should be OK. If plgchr(=
)
> returns a wrong height, everything gets messed.
> Could your changes related with fonts and aspect-ratio have some impact o=
n
> this?

Answered above.  I have never tried to make multi-line legends like in your
examples, but certainly for single-line legends I believe there is a way
to do it in a pixel-independent way, and I have outlined above a way to
do that for multi-lined legends as well.

> | Also, page 1 of the p15 plot and page 1 of the p7 plot are missing
> | a lot of the plot that is visible with the postscript driver.  I think =
it
> | is a colour initialization problem in both cases that might be fixed by
> | setting the colour at the start of each octave example rather than rely=
ing
> | on default values.  (I have run into this problem before with the octav=
e
> | examples; the colour results depend on the order you run the plots, and=
 the
> | driver.)
>
> Could you give a recipe to make it fail?

Yes, use plplot-test.sh. If you cannot replicate this default colour proble=
m
with a clean checkout, then we will have to look deeper at the differences
between our two machines.

>
> | All png results differed from previous which is expected because I am n=
ow
> ...
>
> | NEW RELEASE?
> |
> | If somebody is willing to fix the two mentioned postscript problems, an=
d
> | Joao sorts out the legend coordinate and colour initialization problems=
 for
> | the octave examples, I think that would put us in good position to rele=
ase
> | 5.1.0 as a stable release in the near future featuring the dynamic driv=
ers
> | and the new java stuff (if I can figure out how to test it).  This
> | presupposes that it will be some time (because of his new job pressures=
)
> | beofe Rafael can start integrating his AM/LT changes.
> |
> | What do the rest of you think of this release strategy?
>
> Thats OK to release often, but call it 5.1.0 is too much, as there are st=
ill
> many loose things to fix.

I don't intend to bring it out until you and everybody else here feels it i=
s
ready for release that is as stable as 5.0.4. However, I start thinking
about stable releases when I can do all my research plots from CVS HEAD
without serious bugs showing up, and that is certainly the case now.  We do
have the segfault problem to clear up and the map problem for the test
examples, but those are the only two serious bugs I know about that have
been introduced since 5.0.4.

For now, let's concentrate on the next step between us which is to find out
why we are getting different octave results (png legend size, default
colours, etc.) If you cannot see the problems I have found with running
plplot-test.sh with png driver for a fresh checkout of plplot, then it migh=
t
have something to do with our different octave versions.

Alan