Hello David,
The ThermometerPlot class has provision for setting its min and max values, but even though I specified a range from 0 to 200, the tick marks are labelled 0,20,40,60,80,100 - with 100 near the top of the stem.
I passed the min and max values in as constructor arguments to DefaultMeterDataset; is there some other method I've overlooked, or is this a buglet?
Also, does choosing UNITS_NONE interact with this? The thermometer plot is a useful metaphor even when the data isn't measured in Celsius or Fahrenheit units - it would be a shame to prevent its use in non-temperature contexts.
Thanks,
Irv
ThermometerPlot max? (0.9.6)
Re: ThermometerPlot max? (0.9.6)
Hi Irv,
I agree with you...there are some things that could be changed in the thermometer plot to make it more generic (and probably simpler).
One thing that I've wanted to do for a while is replace the MeterDataset that is used by the ThermometerPlot now, with a new ValueDataset interface that just returns a single value. I think the MeterDataset interface mixes up data (the current value) with presentation (the various sub-ranges).
This will get done before 1.0.0 is released.
Regards,
Dave Gilbert
I agree with you...there are some things that could be changed in the thermometer plot to make it more generic (and probably simpler).
One thing that I've wanted to do for a while is replace the MeterDataset that is used by the ThermometerPlot now, with a new ValueDataset interface that just returns a single value. I think the MeterDataset interface mixes up data (the current value) with presentation (the various sub-ranges).
This will get done before 1.0.0 is released.
Regards,
Dave Gilbert
Re: ThermometerPlot max? (0.9.6)
Irv
I also agree with DG. From the doco for thermometerplot.
* NOTE:
* The Thermometer plot utilises a meter data set, however range options within this data set
* are not used (instead, the ranges can be set as attributes on the plot).
This would explain why setting the values against the meterdataset was not reflected in the display. You need to set against the thermometer, itself. (So as DG said, using a ValueDataset would be better, but as there is not yet a ValueDataset)
Setting UNITS_NONE via setUnits method has no interact with the ranges at all. It simply, as you indicate, control the display of units on the thermometer.
Hey, it is cool that someone else is using it.
Bryan.
I also agree with DG. From the doco for thermometerplot.
* NOTE:
* The Thermometer plot utilises a meter data set, however range options within this data set
* are not used (instead, the ranges can be set as attributes on the plot).
This would explain why setting the values against the meterdataset was not reflected in the display. You need to set against the thermometer, itself. (So as DG said, using a ValueDataset would be better, but as there is not yet a ValueDataset)
Setting UNITS_NONE via setUnits method has no interact with the ranges at all. It simply, as you indicate, control the display of units on the thermometer.
Hey, it is cool that someone else is using it.
Bryan.
Re: ThermometerPlot max? (0.9.6)
Hi Bryan (and David),
You've hit the nail on the head: " You need to set against the thermometer, itself. " Eventually I did discover that, and got the basic ThermometerPlot working nicely. Actually, I used "JThermometer" to simplify (slightly) the code that uses it - although I did add some access functions so I could modify the the enclosed ThermometerPlot's TickLabelFont.
However, now that it basically works, I'd really like to improve its appearance. The version currently included in jfreechart-0.9.6.jar seems to be designed as a square panel, and as such it leaves a _lot_ of white space on each side of the thermometer itself (especially when displayed with "UNITS_NONE".) Thanks to the scaling properties of Java2D, if the space allocated to a ThermometerPlot (or JThermometer) is taller than it is wide, both the thermometer "bulb" and all numeric text get squeezed together in the horizontal direction.
Since the overall component has excess white space on each side of the actual "thermometer", it seems as if the text and thermometer _could_ be allowed to expand into the white space, preserving a circular bulb and readable text , at least until clipping intervenes. I've been squinting at the code, but would really appreciate some "hints" as to how this might be done. (Maybe what I need is a primer on image-scaling in Java2D, if you can recommend a concise summary someplace?)
Thanks in advance for any suggestions,
Irv Thomae
You've hit the nail on the head: " You need to set against the thermometer, itself. " Eventually I did discover that, and got the basic ThermometerPlot working nicely. Actually, I used "JThermometer" to simplify (slightly) the code that uses it - although I did add some access functions so I could modify the the enclosed ThermometerPlot's TickLabelFont.
However, now that it basically works, I'd really like to improve its appearance. The version currently included in jfreechart-0.9.6.jar seems to be designed as a square panel, and as such it leaves a _lot_ of white space on each side of the thermometer itself (especially when displayed with "UNITS_NONE".) Thanks to the scaling properties of Java2D, if the space allocated to a ThermometerPlot (or JThermometer) is taller than it is wide, both the thermometer "bulb" and all numeric text get squeezed together in the horizontal direction.
Since the overall component has excess white space on each side of the actual "thermometer", it seems as if the text and thermometer _could_ be allowed to expand into the white space, preserving a circular bulb and readable text , at least until clipping intervenes. I've been squinting at the code, but would really appreciate some "hints" as to how this might be done. (Maybe what I need is a primer on image-scaling in Java2D, if you can recommend a concise summary someplace?)
Thanks in advance for any suggestions,
Irv Thomae
Re: ThermometerPlot max? (0.9.6)
Hi Irv,
The thermometer gets drawn in the draw(...) method in the ThermometerPlot class, I guess you could mess about with the various dimensions in there to get a different look.
> recommend a concise summary someplace?
Everything I know about Java 2D is from:
(1) the O'Reilly book "Java 2D Graphics" by Jonathan Knudsen;
(2) the Javadocs;
(3) trial and error;
I'd recommend all of the above, (1) being a good place to start.
Regards,
Dave Gilbert
The thermometer gets drawn in the draw(...) method in the ThermometerPlot class, I guess you could mess about with the various dimensions in there to get a different look.
> recommend a concise summary someplace?
Everything I know about Java 2D is from:
(1) the O'Reilly book "Java 2D Graphics" by Jonathan Knudsen;
(2) the Javadocs;
(3) trial and error;
I'd recommend all of the above, (1) being a good place to start.
Regards,
Dave Gilbert
Re: ThermometerPlot max? (0.9.6)
Hi David,
Searching the Javadocs for class Graphics2D, I found a method called scale(xscale, yscale). It worked very nicely.
The first argument to ThermometerPlot.draw() is the Graphics2D context 'g2'.
I added the following 4 lines at the very start of draw():
double ht = plotArea.getHeight();
double wd = plotArea.getWidth();
double scaler = wd/ht; // calculate reciprocal of the aspect ratio
g2.scale(scaler, 1.0); // scale all horizontal dimensions by that factor
Applying the scale() operation to 'g2' in this way corrects both text and drawn objects, so that they no longer appear "squeezed". A more general solution might include adding a flag to the ThermometerPlot class which would govern whether the scale() is actually called, and/or a check for aspect ratios so extreme that after correction, text would no longer fit within the available width - but for my purposes, this simple "fix" works very well indeed.
Yet another reason for all of us to be glad that you chose to make jFreeChart open-source.
Thanks,
Irv Thomae
Searching the Javadocs for class Graphics2D, I found a method called scale(xscale, yscale). It worked very nicely.
The first argument to ThermometerPlot.draw() is the Graphics2D context 'g2'.
I added the following 4 lines at the very start of draw():
double ht = plotArea.getHeight();
double wd = plotArea.getWidth();
double scaler = wd/ht; // calculate reciprocal of the aspect ratio
g2.scale(scaler, 1.0); // scale all horizontal dimensions by that factor
Applying the scale() operation to 'g2' in this way corrects both text and drawn objects, so that they no longer appear "squeezed". A more general solution might include adding a flag to the ThermometerPlot class which would govern whether the scale() is actually called, and/or a check for aspect ratios so extreme that after correction, text would no longer fit within the available width - but for my purposes, this simple "fix" works very well indeed.
Yet another reason for all of us to be glad that you chose to make jFreeChart open-source.
Thanks,
Irv Thomae
Re: ThermometerPlot max? (0.9.6)
Irv
If I am understanding you correctly. The problem you are describing arises
because both BULB_RADIUS and COLUMN_RADIUS are fixed and static values.
Bryan
If I am understanding you correctly. The problem you are describing arises
because both BULB_RADIUS and COLUMN_RADIUS are fixed and static values.
Bryan
Re: ThermometerPlot max? (0.9.6)
(Responding to Bryan)
No, this has nothing to do with the radii being fixed sizes. The graphical layout assumed by ThermometerPlot's draw() method is a square screen area., i.e. a ractangle with a 1::1 aspect ratio. As one of the demo programs shows, when that is in fact true, there's quite a lot of white space on each side of the "thermometer" picture.
But jFreeChart is built on Java2D, which is a pretty clever package. As you embed ThermometerPlot within a more complex graphical layout, it is perfectly reasonable to impose size constraints on it that change the aspect ratio.
When Java2D discovers that you've done this, it automatically scales down _all_ horizontal coordinates, even those involved in drawing the text TickLabels, etc. Everything looks "squeezed" together, and the result is neither attractive nor easy to read.
Since the squeeze-factor comes directly from the aspect ratio, I've added an explicit scaling operation which uses the reciprocal of that aspect ratio. The "product" of the automatic scaling with my added scale() step is again 1::1, so that the text is restored to normal appearance, and the thermometer no longer looks badly squeezed (although the "bulb" is still
somewhat elliptical, rather than circular.)
Because Java2D also clips whatever it draws so as to fit within the screen area in question, there are practical limits to what this "fix" can do. Although it works nicely when the aspect ratio is on the order of 3:: 4 (width::ht), I wouldn't expect it to look very good when the available area is less than half as wide as it is high.
No, this has nothing to do with the radii being fixed sizes. The graphical layout assumed by ThermometerPlot's draw() method is a square screen area., i.e. a ractangle with a 1::1 aspect ratio. As one of the demo programs shows, when that is in fact true, there's quite a lot of white space on each side of the "thermometer" picture.
But jFreeChart is built on Java2D, which is a pretty clever package. As you embed ThermometerPlot within a more complex graphical layout, it is perfectly reasonable to impose size constraints on it that change the aspect ratio.
When Java2D discovers that you've done this, it automatically scales down _all_ horizontal coordinates, even those involved in drawing the text TickLabels, etc. Everything looks "squeezed" together, and the result is neither attractive nor easy to read.
Since the squeeze-factor comes directly from the aspect ratio, I've added an explicit scaling operation which uses the reciprocal of that aspect ratio. The "product" of the automatic scaling with my added scale() step is again 1::1, so that the text is restored to normal appearance, and the thermometer no longer looks badly squeezed (although the "bulb" is still
somewhat elliptical, rather than circular.)
Because Java2D also clips whatever it draws so as to fit within the screen area in question, there are practical limits to what this "fix" can do. Although it works nicely when the aspect ratio is on the order of 3:: 4 (width::ht), I wouldn't expect it to look very good when the available area is less than half as wide as it is high.