[GRASS-user] Horizontal legend font size

[Glynn Clements]

Hamish wrote:

> > > As a general solution, I wonder if we should add a new enviro var
> > > GRASS_TEXT_SIZE, which R_text_size() would look for. If it was set
> > > it would override whatever was passed to that fn. (use for both width
> > > and height options which are usually the same)
> 
> Glynn:
> > And also GRASS_LINE_WIDTH.
> 
> ok
> 
> > And maybe GRASS_FRAME=t,b,l,r.
> 
> what about current frame name?
> will frames even survive in some form for GRASS 7?

The display library maintains a single active frame. Frames don't
persist from one command to the next (hence d.frame no longer exists),
and a program can't create multiple named frames then switch between
them by name (which is one of the reasons why d.profile doesn't
compile).

But a program can choose to use a portion of the "screen" rather than
all of it, by using D_new_window[_percent]() (the name parameter is
kept for compatibility, but is ignored).

> > But not text rotation.
> 
> what's different about that one?

I can't see any situation where the user would want to set it. Rotated
text only really makes sense if the program decides that it wants
rotated text, and allows for the rotation when positioning it.

Most programs arrange text based upon the text size and number of
characters, with an implicit assumption that it will be drawn
horizontally. The few that use rotated text set the rotation
themselves.

> > And then change all of these environment variables into
> > GRASS variables, and provide a d.config program to set/get them.
> > R_font(), R_text_size(), R_line_width() etc would still exist, but
> > would only change the settings for the current process, not
> > persistently.
> 
> and thus knock away a few more global variables from libgis...
> I would wait to make them GRASS variables (and remove global) until
> grass7.

Everything which I'm proposing or actively working on is in relation
to GRASS 7.

I don't see much point to trying to add minor enhancements to the
display architecture for 6.x. And even if there was some point, it's
too much work.

Making even minor changes is a lot of work with the old architecture,
which is why I've gutted it for 7.x (e.g.: lib/raster is now precisely
one file, and 90% of that is wrappers; there's only 25 lines of "real"
code in total).

> > We probably also want a global scale setting, which would affect
> > various dimensions which are currently hard-coded, e.g. the size of
> > axis ticks, etc.
> 
> I'll have to think about that more.
> 
> 
> about d.legend's auto font auto-sizing based on legend length- I was
> thinking about changing the calculation to be non-linear & so more even
> a size from both a 250 pixel wide legend and a full width legend. Which
> for normal use at current monitor size and resolution is great, but for
> things like oversampling 4x then cubic rescale in GIMP for pretty output
> or for the PS/SVG/etc drivers I wonder if it is better to keep it
> perfectly scaled to the frame size rather than expecting the view to
> always be targeted to the same number of pixels on the monitor.

Yes. Using fixed sizes is meaningless, due to vector output,
oversampling, 250dpi monitors, etc.

At some point I may add a global scale variable, so that a 640x480
image could be 6400x4800 units (scale=10) or 64x48 units (scale=0.1)
or anything. The idea is to catch any code which hard-codes
dimensions.

Even scaling to "screen" size (i.e. using percentages) isn't always a
solution. You probably don't want the same relative proportions for
both a 640x480 PNG file and an A0 poster.

-- 
Glynn Clements <glynn at gclements.plus.com>