Menu
▾
▴
gnuplot-beta
|
From: Andreas K. H. <And...@Ph...> - 2005-01-06 16:05:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear developers, I just checked out the CVS version and was amazed that work has been done on all the "killer features" I've been missing in 4.0 - THANK YOU!!! (especially "with image", "set ytics offset ...", string variables) Anyway, here's one bugreport and one feature request (for details, see also http://www2.nano.physik.uni-muenchen.de/~huettel/gnuplot/ ): 1) when I use identical data and an identical macro for "with pm3d" and "with image" (postscript terminal), the image is drawn much too big and covers the lower plot border. do you have any idea how to fix this? (for examples see above url) 2) is there any way to set the "missing data" color for "with image" (and perhaps "with pm3d") ? I.e., I am doing many log plots with noisy data, and "low value" means "white" in my palette. I'd very much like to be able to set "missing data" as "white", since thats what (minimally) negative values end up as.... Thanks a lot in advance, Andreas - --------------------------------------------------------------------- Dipl.-Phys. Andreas K. Huettel tel. +49 89 2180 3349 (univ.) Sektion Physik der LMU fax +49 89 2180 3182 (univ.) LS Prof. J.P. Kotthaus hu...@lm... Geschwister-Scholl-Platz 1 ma...@ak... 80539 Muenchen and...@ph... Germany http://www.akhuettel.de/research/ - --------------------------------------------------------------------- Privat: Andreas K. Huettel, Enhuberstrasse 5, 80333 Muenchen, Germany - --------------------------------------------------------------------- Please use GNUPG or PGP for signed and encrypted email. My public key can be found at http://www.akhuettel.de/pgp_key.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFB3WHIL+gLs3iH94cRAoOsAJwNI7SeUJa6nMmEOf9cxSeJ/hszlQCfRtJo tDyJCSP6kfh+1eSSAr42cg4= =yp2p -----END PGP SIGNATURE----- |
|
From: Petr M. <mi...@ph...> - 2005-01-06 17:42:03
|
> 1) when I use identical data and an identical macro for "with pm3d" and > "with image" (postscript terminal), the image is drawn much too big and > covers the lower plot border. do you have any idea how to fix this? > (for examples see above url) In pm3d, you can use "set pm3d clip..." settings. > 2) is there any way to set the "missing data" color for "with image" (and > perhaps "with pm3d") ? > I.e., I am doing many log plots with noisy data, and "low value" means > "white" in my palette. I'd very much like to be able to set "missing data" > as "white", since thats what (minimally) negative values end up as.... For pm3d, either miss them in the data file, or set a z-range, or use different z-range and cb-range; set zrange [10:1e8] will invalidate all data out of the above range. That cannot be done for "with image" for principal reasons -- that's to draw a matrix, so all pts must be valid. Thus, you have to make a palette with one color white and use the corresponding value for coloring your special pixels. --- PM |
|
From: Andreas K. H. <And...@Ph...> - 2005-01-06 18:33:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Mr Mikulik, #]> 1) when I use identical data and an identical macro for "with pm3d" and #]> "with image" (postscript terminal), the image is drawn much too big and #]> covers the lower plot border. do you have any idea how to fix this? #]> (for examples see above url) #] #]In pm3d, you can use "set pm3d clip..." settings. I'm sorry, I have not expressed myself clearly enough... everything is working perfectly with pm3d mode. Its just that when I use the same parameters for "with image" mode instead, then the color plot is scaled incorrectly and does not fit into the "axes frame". #]> 2) is there any way to set the "missing data" color for "with image" (and #]> perhaps "with pm3d") ? (...) #] #]For pm3d, either miss them in the data file, or set a z-range, or use #]different z-range and cb-range; #] set zrange [10:1e8] #]will invalidate all data out of the above range. Do I understand this correctly that in pm3d map mode the zrange controls whether points are "drawn", i.e. whether for example in a postscript image the background is visible or not? #]That cannot be done for "with image" for principal reasons -- that's to draw #]a matrix, so all pts must be valid. Thus, you have to make a palette with #]one color white and use the corresponding value for coloring your special #]pixels. Sure... what I was asking is: is there any way to set this special color value? regards, Andreas - --------------------------------------------------------------------- Dipl.-Phys. Andreas K. Huettel tel. +49 89 2180 3349 (univ.) Sektion Physik der LMU fax +49 89 2180 3182 (univ.) LS Prof. J.P. Kotthaus hu...@lm... Geschwister-Scholl-Platz 1 ma...@ak... 80539 Muenchen and...@ph... Germany http://www.akhuettel.de/research/ - --------------------------------------------------------------------- Privat: Andreas K. Huettel, Enhuberstrasse 5, 80333 Muenchen, Germany - --------------------------------------------------------------------- Please use GNUPG or PGP for signed and encrypted email. My public key can be found at http://www.akhuettel.de/pgp_key.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFB3YRrL+gLs3iH94cRAoXQAKCOtQnPG9WBIRSDGsBnIhGv+G23wgCcDZwH lGEIGMqQNzQolsJqP8MSStA= =9F+s -----END PGP SIGNATURE----- |
|
From: Petr M. <mi...@ph...> - 2005-01-07 07:43:12
|
> #]> 2) is there any way to set the "missing data" color for "with image" (and > #]> perhaps "with pm3d") ? > (...) > #] > #]For pm3d, either miss them in the data file, or set a z-range, or use > #]different z-range and cb-range; > #] set zrange [10:1e8] > #]will invalidate all data out of the above range. > > Do I understand this correctly that in pm3d map mode the zrange controls > whether points are "drawn", i.e. whether for example in a postscript image > the background is visible or not? Yes, invalid quadrangles are not drawn. > #]That cannot be done for "with image" for principal reasons -- that's to draw > #]a matrix, so all pts must be valid. Thus, you have to make a palette with > #]one color white and use the corresponding value for coloring your special > #]pixels. > > Sure... what I was asking is: is there any way to set this special color > value? No; I overcome it by the above method. It may be really useful to add such a "masking" color, chooseable like the current "textcolor". You could try to make a proposal for syntax with comments on functionality. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 08:01:43
|
Anyone familiar with CorelDraw? Someone's having a problem importing a
gnuplot PostScript image of indexed palette type. (Apparently the color
images import fine.) The result in CorelDraw is a black rectangle. The
PostScript image remains visible in stuff like Ghostview, GIMP, etc.
The gnuplot syntax for indexed images is below. I've done a web search
and can't find any cases of CorelDraw users reporting such behavior.
Dan
%%BeginImage
gsave
987 3853 translate
5562 -3326 scale
%%BeginPalette
[ /Indexed
/DeviceRGB 255
<
000000 100006 17000d 1c0013 200019 24001f 270026 2a002c
<snip>
fbeb00 fced00 fcf000 fdf300 fdf600 fef900 fefc00 ffff00
>
] setcolorspace
%%EndPalette
<<
/ImageType 1
/Width 128
/Height 128
/BitsPerComponent 8
/ImageMatrix [ 128 0 0 128 0 0 ]
/Decode [ 0 255 ]
/imagebuf 16384 string def
/DataSource {currentfile imagebuf readhexstring pop}
/MultipleDataSources false
/Interpolate false
>>
image
e8e8e8e8e8e8e8e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9
<snip>
81818181
grestore
%%EndImage
|
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 08:15:35
|
Daniel J Sebald wrote: > I've done a web search and can't find any cases of CorelDraw users > reporting such behavior. I'm just curious if it is a problem with gnuplot images. |
|
From: Daniel J S. <dan...@ie...> - 2005-01-07 02:29:06
|
Andreas K. Huettel wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Dear developers, > >I just checked out the CVS version and was amazed that work has been done >on all the "killer features" I've been missing in 4.0 - THANK YOU!!! >(especially "with image", "set ytics offset ...", string variables) > >Anyway, here's one bugreport and one feature request (for details, >see also http://www2.nano.physik.uni-muenchen.de/~huettel/gnuplot/ ): > >1) when I use identical data and an identical macro for "with pm3d" and >"with image" (postscript terminal), the image is drawn much too big and >covers the lower plot border. do you have any idea how to fix this? >(for examples see above url) > That is a strange one. I assume you have an image for which you select a range that is only a portion of the image. This is supposed to work fine. I will have a look this weekend. (I'm just back from a few days of meetings.) In the mean time, perhaps you could run the demo "image.dem" and cross-reference against the file: http://acer-access.com/~ds...@ac.../gnuplot/image.pdf If there are differences, please let me know or send a PDF file or compressed PostScript file. (There are some examples in the demo which show only a subregion of an image. Thanks, Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-01-07 07:01:19
|
Daniel J Sebald wrote: > Andreas K. Huettel wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Dear developers, >> I just checked out the CVS version and was amazed that work has been >> done on all the "killer features" I've been missing in 4.0 - THANK >> YOU!!! >> (especially "with image", "set ytics offset ...", string variables) >> >> Anyway, here's one bugreport and one feature request (for details, >> see also http://www2.nano.physik.uni-muenchen.de/~huettel/gnuplot/ ): >> >> 1) when I use identical data and an identical macro for "with pm3d" >> and "with image" (postscript terminal), the image is drawn much too >> big and covers the lower plot border. do you have any idea how to fix >> this? >> (for examples see above url) >> > > That is a strange one. I assume you have an image for which you > select a range that is only a portion of the image. This is supposed > to work fine. I will have a look this weekend. Actually, now that I look closely, I see there _aren't_ any such demos in image.dem. (I will add such an example.) I know this works in the X term driver. But I don't think any of us thought to check this out in all the terminals (i.e., PostScript, PDF, PNG, etc.). In fact, OK, I just checked a range clipped image example using the PNG terminal driver. It fails. There are two sets of coordinates sent through the terminal image call, the location of the image and the visible area. (For systems that can display portions of pixels on the edge.) I'll go through the terminals one at a time and let you know when they are ready. Thanks for find this, Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 02:30:44
|
Petr, I'm going to send you a patch file for correcting a problem with scaling that Andreas found in the image routines for splot mode. (The splot was using the outer limits for plot, hence the images were coming out bigger than expected.) There is also a better routine for determining what portion of the image is within the range volume of the splot. Please apply the patch as one or two bug fixes. Also, in looking at a problem with PostScript palettes (one still unresolved but may be a problem with the application and not Gnuplot), I was reminded of a patch that Ethan and I created for better handling Level1 and Level2 PostScripting. It doesn't seem like that was moved in yet. We didn't have access to a PostScript Level 1 only application so technically haven't tested it. However, I think what was in the patch was an improvement. It was a fairly big patch (not more code, big because of reshuffling of code), so the risk of an unforseen bug is probably less than forgetting about the patch some day. Ethan, should we move that into CVS? (The latest date I have is "image_post_19sep2004.patch.gz".) Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 02:41:26
|
I've been using gnuplot quite a bit lately. It's been working very well, which says a lot about the amount of work put in over the last few years. The only annoying thing right now is the layout for plots when in square mode. It's easy enough to modify the bounding box in an EPS file, but it sure would be nice if some brave soul could slay that dragon. Dan |
|
From: Petr M. <mi...@ph...> - 2005-01-10 14:30:00
|
> I've been using gnuplot quite a bit lately. It's been working very > well, which says a lot about the amount of work put in over the last few > years. > > The only annoying thing right now is the layout for plots when in square > mode. It's easy enough to modify the bounding box in an EPS file, but > it sure would be nice if some brave soul could slay that dragon. You mean "with image"? I think that the current bounding box calculator does not include the colour box. -- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 18:36:52
|
Petr Mikulik wrote: >>I've been using gnuplot quite a bit lately. It's been working very >>well, which says a lot about the amount of work put in over the last few >>years. >> >>The only annoying thing right now is the layout for plots when in square >>mode. It's easy enough to modify the bounding box in an EPS file, but >>it sure would be nice if some brave soul could slay that dragon. >> >> > >You mean "with image"? I think that the current bounding box calculator does >not include the colour box. > No, I meant the "set size square" problem. Gnuplot creates a plot that is square. However, the whitespace it leaves is still the same aspect ratio as the default. Hence there is a chunk of whitespace on the right side. A while back I put a patch on SF that balances the white space on both sides. It looks better, but actually--as Ethan pointed out--it's hardly an improvement and there is a proper way of correcting it. (One has to modify two borders in the PostScript file, or whatnot, rather than one.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-10 19:20:06
|
On Monday 10 January 2005 10:38 am, Daniel J Sebald wrote: > > No, I meant the "set size square" problem. Gnuplot creates a plot that > is square. However, the whitespace it leaves is still the same aspect > ratio as the default. I would claim that is the correct thing for it to do. The size of the "page" should be set at the terminal level. The size and aspect ratio of the "plot" should be set by the core command "set size". This is how it works for multiplot, right? If you change things so that "set size" affects the whole page size, then won't it totally break multiplot? If you want a square plot on a square page, then you need to do something like: set term png size 500,500 set size square For the png driver there is the additional option of using set term png crop set size square which may be closer to what you are looking for. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 19:46:26
|
Ethan Merritt wrote: >On Monday 10 January 2005 10:38 am, Daniel J Sebald wrote: > > >>No, I meant the "set size square" problem. Gnuplot creates a plot that >>is square. However, the whitespace it leaves is still the same aspect >>ratio as the default. >> >> > >I would claim that is the correct thing for it to do. > >The size of the "page" should be set at the terminal level. >The size and aspect ratio of the "plot" should be set by >the core command "set size". This is how it works for >multiplot, right? > > I suppose you are correct. However, I think we are left with the same trial-and-error-ish-ness. >If you change things so that "set size" affects the whole >page size, then won't it totally break multiplot? > >If you want a square plot on a square page, then you need to do >something like: > > set term png size 500,500 > set size square > > PostScript doesn't have a size (or more appropriately BoundingBox) specification. But still, what would be the difference of having to tweak the values in the PostScript file or at the "set term" line? In the former case at least you can just modify the number and reload the PS file in Ghostview. In the latter case one must continually reissue the plotting sequence of commands, then reload the PS file in Ghostview. I just tried an example with the above PNG syntax. With a color box on the right side, and the square image, and the 500 by 500 output, there remains whitespace now at the top of the image. >For the png driver there is the additional option of using > > set term png crop > set size square > >which may be closer to what you are looking for. > > YES!!!!!!!! Everything fine trimmed right up to the first non-white pixels. Perfect. Every terminal should have such an option. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-10 20:13:31
|
On Monday 10 January 2005 11:48 am, Daniel J Sebald wrote: > > >For the png driver there is the additional option of using > > > > set term png crop > > YES!!!!!!!! Everything fine trimmed right up to the first non-white > pixels. Perfect. Every terminal should have such an option. Feel free to contribute one for your favorite driver. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-10 21:58:35
|
Ethan Merritt wrote: >On Monday 10 January 2005 11:48 am, Daniel J Sebald wrote: > > >>>For the png driver there is the additional option of using >>> >>> set term png crop >>> >>> >>YES!!!!!!!! Everything fine trimmed right up to the first non-white >>pixels. Perfect. Every terminal should have such an option. >> >> > >Feel free to contribute one for your favorite driver. > Well, this is what I'm wondering. Is this feature as straightforward in, say, PostScript as it might be in PNG? I haven't looked, but I imagine PNG , being pixel-based, can easily tell where it's limits are. But with PostScript, you have plot layout in terms of elements like fonts, lines, etc. That might be a more difficult problem, and in fact it might be easier to do the cropping at a higher level of gnuplot's plot layout. Heck, couldn't the word "crop" be worked into one of the plotting commands. So, given what various people know about page layout, what does everyone think about the way of approaching this? A higher level cropping of the image? Or a more low-level crop for each terminal? Dan |
|
From: Petr M. <mi...@ph...> - 2005-01-11 09:58:57
|
> >>>For the png driver there is the additional option of using > >>> set term png crop > >>> > >>YES!!!!!!!! Everything fine trimmed right up to the first non-white > >>pixels. Perfect. Every terminal should have such an option. > > > >Feel free to contribute one for your favorite driver. > > > Well, this is what I'm wondering. Is this feature as straightforward > in, say, PostScript as it might be in PNG? Yes, once the postscript file is completely written -- that's how fixbb, "gs -DEVICE=bbox" or epstool work. For figures, I always do fixbb blabla.eps whatever application produced the eps file. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-01-11 11:20:19
|
Petr Mikulik wrote: >>>>>For the png driver there is the additional option of using >>>>> set term png crop >>>>> >>>>> >>>>> >>>>YES!!!!!!!! Everything fine trimmed right up to the first non-white >>>>pixels. Perfect. Every terminal should have such an option. >>>> >>>> >>>Feel free to contribute one for your favorite driver. >>> >>> >>> >>Well, this is what I'm wondering. Is this feature as straightforward >>in, say, PostScript as it might be in PNG? >> >> > >Yes, once the postscript file is completely written -- that's how fixbb, "gs >-DEVICE=bbox" or epstool work. For figures, I always do > fixbb blabla.eps >whatever application produced the eps file. > > OK. I see this is listed right there on the gnuplot web page. (Oy.) Unfortunately, the link is forbidden. Dan |
|
From: Petr M. <mi...@ph...> - 2005-01-11 13:30:28
|
> >Yes, once the postscript file is completely written -- that's how fixbb, "gs > >-DEVICE=bbox" or epstool work. For figures, I always do > > fixbb blabla.eps > >whatever application produced the eps file. > > OK. I see this is listed right there on the gnuplot web page. (Oy.) > Unfortunately, the link is forbidden. Lars, please "chmod -x" all your files in gnuplot.sf.net:scripts/files/ --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-10 23:31:11
|
On Monday 10 January 2005 02:00 pm, Daniel J Sebald wrote: > So, given what various people know about page layout, what does everyone > think about the way of approaching this? A higher level cropping of the > image? Or a more low-level crop for each terminal? There's no way you could do it in the core code. For some terminals, including PostScript, it is not possible to do it at all, since the physical "pixels" occupied by characters are determined by the font present in your ultimate output device. Nobody upstream of that can predict them perfectly. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-11 04:31:08
|
Ethan Merritt wrote:
>>left edge and whatever ends up with white space, right or top, so be
>>it. In the case of "square" size it's as though one anchors from the lower,
>>
>>
> <>
>
> In a word: no. Not the way the code is currently laid out.
> You'd enter a possibly infinite cycle of re-adjusting and recalculating
> and re-laying out and retesting.
Maybe this can be made to work out. In a few weeks I will have a look;
perhaps I'll revisit the key patch at the same time since it is related.
Also, in some patch I think I once put code that balanced the left and
right or top and bottom whitespace in the case of "square". I'd like to
propose putting that back in if I can find it again. It looked so much
better in X11 plots. Also, I bet it would look a whole lot better with
multiplot subplots that use the square size option, in all terminals.
I just think there is no case where a user wants that extra white space
in an EPS file that comes about from "square". It's tolerable in X11,
but not as an imported graphic.
First, there is a philosophical restriction here in that the BoundingBox
must be output before other PostScript command are. I don't think we
want to approach this by, say, rerouting PostScript commands to a temp
file, computing the BoundingBox, generating header in desired output
file, then dumping the temp file to the desired output file. No? So
that means we must stay away from a terminal level solution?
That being the case, the multiplot plots really pose a problem because
each multiplot plot is done as a separate plot command. There is
absolutely no way to generate BoundingBox information in that situation
because we are forced to send out plots before closing the multiplot.
This may not be such a severe limitation. In the case of multiplot,
unless ones specifies all subplots sizes "square", there will be some
whitespace that can't be removed.
OK, so let's just consider the single plot scenario. In the code are
the following few commands when starting a plot.
/* EAM June 2003 - Although the comment below implies that font
dimensions
* are known after term_init(), this is not true at least for the X11
* driver. X11 fonts are not set until an actual display window is
* opened, and that happens in term->graphics(), which is called from
* term_start_plot().
*/
term_init(); /* may set xmax/ymax */
term_start_plot();
/* compute boundary for plot (xleft, xright, ytop, ybot)
* also calculates tics, since xtics depend on xleft
* but xleft depends on ytics. Boundary calculations depend
* on term->v_char etc, so terminal must be initialised first.
*/
boundary(plots, pcount);
term_init() is where the BoundingBox is written. I believe that
boundary() is where axes etc. are computed, but nothing is written to
the terminal. So, if boundary() could be moved before
"term_start_plot()" and BoundingBox could be written inside
term_start_plot() we might have knowledge of the extent of the image
before writing the BoundingBox. Could the bounding box info be passed
into the terminal via the "options" function and most terminals just
ignore it?
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-11 05:07:53
|
On Monday 10 January 2005 08:33 pm, Daniel J Sebald wrote: > > I just think there is no case where a user wants that extra white space > in an EPS file that comes about from "square". It's tolerable in X11, > but not as an imported graphic. Disagree. I usually need an imported graphic to fit in an allocated *vertical* space, while the horizontal size is set by the column width. I want to specify size in column-inches, and any resulting whitespace on the edges is an expected consequence. Anyhow, if you don't like the bounding box on a particular eps plot, just call up ghostscript and change it to suit. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-11 05:25:28
|
Ethan Merritt wrote:
>On Monday 10 January 2005 08:33 pm, Daniel J Sebald wrote:
>
>
>>I just think there is no case where a user wants that extra white space
>>in an EPS file that comes about from "square". It's tolerable in X11,
>>but not as an imported graphic.
>>
>>
>
>Disagree. I usually need an imported graphic to fit in an allocated
>*vertical* space, while the horizontal size is set by the column width.
>I want to specify size in column-inches, and any resulting whitespace
>on the edges is an expected consequence.
>
>
That's true. But the amount of white space is easy to control in a word
processor. Usually there is a way to control width and/or height
depending upon whether one wants to maintain aspect ratio, which almost
always I want to do. For example, with LaTeX
/begin{figure*}[t]
/leavevmode
/centering
/epsfig{file=spikespec_ann.eps,width=0.7/columnwidth}
//*
/parbox{/columncaptionwidth}{
/caption{/label{fig:plottwo} Transform of neural spikes from
/reffig{fig:plotone}.}
}
/end{figure*}
formats a graph nicely; if the white space is trimmed away from the
figure that is. Could change the width. Could use height. Both.
Everything is scaled nicely. But if that white space gnuplot adds is
considered part of the width, there is no nice way of getting rid of it
without some bad LaTeX tricks that give errors. That, or things are off
center and space is used up.
>Anyhow, if you don't like the bounding box on a particular eps plot,
>just call up ghostscript and change it to suit.
>
>
I know. But adding an extra step for the user isn't user friendly.
Dan
PS: Just downloaded LyX.
|
|
From: Petr M. <mi...@ph...> - 2005-01-10 14:28:30
|
> I'm going to send you a patch file for correcting a problem with scaling > that Andreas found in the image routines for splot mode. (The splot was > using the outer limits for plot, hence the images were coming out bigger > than expected.) There is also a better routine for determining what > portion of the image is within the range volume of the splot. Please > apply the patch as one or two bug fixes. It has been applied. --- PM |
