Re: Binary installer for Mac OS X

[Per P. <per...@ma...>]

On Oct 2, 2004, at 01:59, Ethan Merritt wrote:

> On Friday 01 October 2004 02:17 pm, Per Persson wrote:
>> What version?
>
> 1.0a2

Please try 1.0b2, comes with installer too.

[snip]

> Never mind.  I just rebooted the machine, and now it works.

Rebooting shouldn't be neccessary.

[snip]

> Looks basically pretty good.  The lack of mouse interaction makes
> it strictly inferior to X, but the plot quality is OK.

Well, AquaTerm support passing events to the client so all we need is 
someone with spare time to hook up the connection...

> The only
> glitches I see in a quick run through all.dem are:
>
> (aquaterm bug): the background of the plot is corrupted whenever
> it overlaps another window.  Not just a transparency effect - 
> overlapping
> even a small corner causes the color to streak across the entire
> horizontal extent of the aquaterm window.

Que? Could you send me a screenshot of this (press SHIFT-CMD-4). I've 
never seen or heard about anything like that.

>
> (pm3d bug): The pm3d surface plots suffer from what looks like the
> same bug we had to squash in postscript a few months back. Every
> individual pm3d rectangle is outlined in white, so the overall plot 
> looks
> either stripy or plaid.  We fixed this in PostScript by doing an extra
> gsave/grestore around the newpath/vectors/fill operation. I don't know
> if there is an equivalent operation in aqua.trm

This should be fixed in 1.0.b2

>
> (general style): It would be nice if the first 10-12 point styles 
> matched
> other terminals. It is annoying to preview a plot on the screen and
> then find when you print it that all the point symbol shapes have 
> changed.
> At the least it should offer open and filled circles (styles 6 and 7).

Agreed, but aquaterm relies on gnuplot to draw the points via 
do_point().
That will probably change in the future.

>
> (fonts): Text placement would be more accurate if the correct font 
> specs
> are passed back to the core code via the TERM_ENTRY fields
> v_char and h_char.  See for instance the box around the sample
> text in the output of "test".  I see that there is code in aqua.trm 
> that
> tries to do this, but it doesn't seem to be getting the correct 
> information.

No, it guesses from the current fontsize. Even if some "correct" 
information was passed to gnuplot, it wouldn't completely solve the 
problem unless the current font has a fixed with. Consider adding 
"iiii" as opposed to "MMMM", the bounding box can only be determined by 
taking both the string and the font into account. But, yes, 
aquaterm.trm should probably put a little more effort into this.

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare