[GRASS-dev] color tables

[Glynn Clements]

Hamish wrote:

> > These should be generated as part of the build process.
> > Otherwise, there's no guarantee that they actually match the colour
> > tables in lib/gis/colors 
> 
> great, looks good.
> 
> One thing I notice is that in grass7 the D_move_abs(), D_cont_rel()
> line widths are heavier than they were in 6.x. (2px vs 1px wide)
> Is it possible to make 1px again? An explicit D_line_width(0) just
> makes it grey,

At present, the output will be affected by $GRASS_RENDER_IMMEDIATE,
$GRASS_LINE_WIDTH, and $GRASS_ANTIALIAS (that's an oversight; I'll
modify the script to unset those).

> I guess it has to be moved 1/2 a pixel from centered
> on grid lines to centered mid-cell?? It seems to work ok in d.legend
> which is pretty much the same code.

You shouldn't assume that the display library will allow that kind of
low-level control. At some point, it may support scaling of "unscaled"
coordinates, so that modules with hard-coded sizes produce usable
results on 200dpi monitors.

Even at present, you don't actually have that degree of control, given
the existence of the PS driver and PS/PDF/SVG output via the cairo
driver.

> Also I notice that for d.colortable and d.legend that with D_end()
> to close the polygon there is a pixel missing from the start/end
> position here. see attached.

Use D_close() if you want a closed path (i.e. a join rather than
caps).

> (hmmm, D_end() is a no-op?)

At present, yes.

> > (shouldn't those have been moved to lib/raster?).
> 
> fwiw they are used by v.colors too. (which will eventually be free
> of r.* hacks)

How are the files going to be read? Is someone planning on duplicating
the contents of lib/raster/color_rules.c for the sake of not using the
raster library? If so, that code should be moved back into lib/gis.

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