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.
Michael Barton wrote:
>> 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.
Most programs which specify text size specify a fixed aspect ratio,
typically identical values for both width and height (although some
modules use a different fixed ratio)
However, d.graph, d.histogram, d.linegraph, and d.mapgraph make the
text size proportional to the screen size, so the text's aspect ratio
will depend upon the screen's aspect ratio.
d.profile sometimes uses a fixed aspect ratio and sometimes matches
the screen's aspect ratio. r.spread squashes text to fit various boxes
which vary according to the screen dimensions.
In most cases, a fixed aspect ratio is desirable. I'll probably
enforce this in 7.x by only allowing a single "size" parameter for the
text size rather than separate width/height.
> 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.
If the functionality is useful enough to have in GRASS, it's useful
enough to have outside of the GUI.
--
Glynn Clements <glynn@gclements.plus.com>
On Jan 31, 2008, at 4:30 AM, Glynn Clements wrote:
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.
If the functionality is useful enough to have in GRASS, it's useful
enough to have outside of the GUI.
Yes. But who is going to code it?
Michael
Michael Barton wrote:
>>> 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.
>
> If the functionality is useful enough to have in GRASS, it's useful
> enough to have outside of the GUI.
>
Yes. But who is going to code it?
The same can be said of any feature. However, adding a GUI-only
version is only going to decrease the chance of a proper version being
implemented; it's essentially a wrecking tactic.
--
Glynn Clements <glynn@gclements.plus.com>