I noted a problem with the fonts in d.histogram and sent a note to
Hamish, mistakingly thinking he had been working on it. He suggested
that I copy the dev list. So here it is.
Michael
Begin forwarded message:
Your fix on the tick marks looks nice. There is still something odd
with the fonts. Here is a screenshot. Also, the font does not scale
with the screen size.
actually Markus fixed it, not me.
the bug report for this:
http://intevation.de/rt/webrt?serial_num=1977
Here is a little more info. When I initially run d.hist and
display it
(I'm doing it in a TclTk canvas), all the letters are in a large font
and bunched up. If I expand the window (i.e., redraw d.hist with
larger
GRASS_WIDTH and GRASS_HEIGHT), the letters space out correctly, but
appear in different sizes (what I sent you). If I then resize back
down
to smaller, the letters eventually go back to a single font and begin
to resize themselves with window size. Resizing the TclTk canvas
cases
a change to the width and height variables, and a redraw of d.hist. I
don't know if this is helpful or not.
..
Now I see why the letters are all squished together. This happens if
the region is roughly square or especially if it is taller than it is
wide. If the region is considerably wider than it is tall (e.g. 3:2)
the letters look OK. It looks like it is using the region height to
specify the typeface point size, and the region width to specify the
leading or horizontal character spacing. It should probably use the
width only for character point size.
cc -dev?
apparently the fonts are scaled per number. I had the same problem in
d.legend until I made it scan for the longest number of characters
before
deciding the scaling amount. A similar approach could be taken here.
(disclaimer: I don't know if anyone would have ever noticed this,
but you can recreate the same effect in d.legend if you flip the
legend upside down so the smallest(shortest # of chars) values are
at the top)
The module is rerun every time the window is resized, so it isn't
surprising that the auto-scaling code will give a different result.
I support using some Python plotting library to draw axes. We could
write
up a grid template using d.graph, but I'd rather be in the business of
gluing together high quality components rather than reinventing
yet-another x-y plotting package. If we like a plotting package but
it lacks the ability to output to PNG or whatever we need, I would
suggest donating the extra code to enhance that package to the
other project.
Your histogram demo looked nice. Next step: add g.parser support
and replace random number generated data with results of r.stats.
r.what.color could be used to get the colors for the midpoint of
each bin.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
