[GRASS-dev] ps.map consolidation

[Glynn Clements]

J-Báchym Čepický wrote:-A

> I started to look into ps.map code and I found few issues, which
> should be IMHO solved, so the code looks a bit nicer and the usage is
> more consistent.
> 
> It would be great, if somebody more skilled would post some comments
> to this topic, I will be very much thankful.
> 
> 1) some instructions (raster, setcolor) do not need to end with "end"
> keyword, where others do.

More precisely, instructions which have options need "end", those
which don't have options don't need "end".

> this should be IMHO consolidated, so that
> ALL instructions will need to end with "end" keyword.

While this may be a reasonable idea, it will break existing ps.map
scripts. The same goes for most of your other suggestions.

If you're going to abandon compatibility, you may as well go all the
way, rather than merely tinkering with the syntax and leaving the
semantics intact.

A better structure, IMHO, would be to execute commands as they are
read from the file, rather than simply storing data then generating
everything at the end. This would allow multiple items (maps etc) on a
page.

Most of the commands should simply dump their parameters (or the GRASS
data to which they refer) to the output file, leaving as much of the
implementation as possible in PostScript. This would allow
customisation without needing to recompile anything.

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