#242 Fixes for PaintScaleLegend
I have noted a few issues with the current PaintScaleLegend:
- changes in the ValueAxis of the PaintScaleLegend do no trigger a redraw since the PaintScaleLegend is not registered as an AxisChangeListener for the axis.
- the stripOutlineVisible flag has no effect. A rectangle around the color strip is always drawn.
- Most importantly: for some combinations of position of the PaintScaleLegend, the axisLocation, the padding of the legend, and the subdivisions count, the color strip is frequently interrupted, and the background shines through!
I have changed the source and made a new file LinePaintScaleLegend.
The LinePaintScaleLegend is registered as AxisChangeListener on the ValueAxis and takes the stripOutlineVisible flag into account.
The drawing principle has changed. The drawing is now performed by determining the size of the area of the color strip in java2D space, stepping through the area from the start to the end with an increment of 1 (i.e. pixel by pixel) and drawing a line for each step. The subdivisions are no longer necessary.
The new class has been briefly tested with a couple of combinations of legend position and axis lcoations and has been found to be stable. After further testing, it could replace the original PaintScaleLegend.
First bug fix. The new drawing algorithm looks fine on a Graphics2D and exported as PNG but looks horrible when exported to PDF (color strip was still interrupted).
The drawing principle was changed and now uses Line2D.Double instances and a stroke that is 2 px wide to draw the individual lines of the color strip.
The new approach also fixed some rounding errors which came from casting of doubles to ints.
It looks ok on a Graphics2D, PNG and as PDF.
File Added: LinePaintScaleLegend.java
color strip is drawn from rectangles
The quality of the output still showed some variations based on the output format if the color strip was drawn from individual lines.
This version draws the color strip from Rectangles with a width or height of 1 (dependent on the position of the LinePaintScaleLegend).
The subdivisions are included again since I tried to dynamically calculate the width/height of the rectangles so that only subdivisions rectangles would be generated. Unfortunately, that suffered from varying output qualities as well.
File Added: LinePaintScaleLegend.java
Hi Peter,
Sorry for the delay on this one. I've committed the bug fixes (register as an axis listener, respect the stripOutlineVisible flag) for inclusion in the 1.0.13 release (hopefully tomorrow!).
Regarding the rendering, I'm not sure of the best fix. I think it helps to round the boundary between each division to an integer, but even that doesn't seem to always work. Did you reach a conclusion when testing your modifications?
Best regards,
Dave Gilbert
JFreeChart Project Leader
Hi David,
separation of the length of the color strip into 1 px long areas and drawing each area as a Rectangle2D.Double with a length of 1 px (exchanged "length" with "width" or "height" depending on the position of the legend) works for most situations, e. g. both Bitmaps and PDFs are rendered fine.
However, last weekend, I found a situation where the new algorithm did not fully work as expected: the "black" end of a GrayPaintScale was obviously rendered in dark gray. I am not sure of the origin, but debugging proved that the color in which the "black" end should be drawn was indeed black. I assume that a subtle interplay of a dark color, antialiasing and a small rectangle size caused this effect. Changing the length of the rectangles from 1.0 to 2.0 while keeping the distance between the rectangles to 1 (i.e. let the rectangles overlap) solved that. The "overlapping rectangle" approach looks also fine as PDF, at least the case that I stumbled on. Thus, rendering the color strip as 2 px wide, overlapping rectangles would be my favourite. For very long color strips, the individual rectangles could probably become longer while maintaining the 1 px overlap in order to avoid the rendering of possibly thousands of rectangles (at one point that might contribute to the overall rendering time or to the size of exported files containing charts in a vector format), but that remains to be tested.
How does this look for you in 1.0.13? I committed a small change that improved my test cases, but I didn't spend any more time on it because I wanted to get the release done.
The "small change" made things look just fine! A test PDF with your original 1.0.13 version was created w/o noteable artifacts and was smaller in file size than the document that I created using the patch.