[GRASS-dev] ps.map consolidation

[Jáchym Čepický]

Thanks for the comments.

I was suggesting this changes to make live of GUI coder easier :)

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

Is the layer approach the one, we should use?

Jachym

2007/3/2, Hamish <hamish_nospam at yahoo.com>:
> Jáchym Èepický wrote:
> > 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. this should be IMHO consolidated, so that
> > ALL instructions will need to end with "end" keyword. we should look
> > into configuration file of mapserver for inspiration
>
> Glynn answered:
> > More precisely, instructions which have options need "end", those
> > which don't have options don't need "end".
>
> The subinstruction code is never called (it doesn't exist), so the
> "end" is never considered. It wouldn't be too hard to have main.c skip
> over any extra "end"s in the control file, but that blurs the (obscure)
> logic.
>
> Jachym:
> > 2) I think, file session.c can be removed. I did not quite understand,
> > what is this session management about, but it would make the code a
> > bit simplier and short test showed, it is working also without it (and
> > I found no other function, which wuold access functions from
> > session.c)
>
> input() [input.c] calls add_to_session() [session.c] if PostScript level
> is >0 (???). the reject() fn in session.c is called in a few places.
> Perhaps this is all for storing input in a tmp file when entering
> commands in interactive mode or when input is piped from stdin??
> It's a case where some comments in the code would have been nice.
>
> Looking way back to the GRASS 4.3 source code I see "session" is a
> KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's
> probably a hold-over from p.map (where it isn't commented out), and
> safely removed. It's not mentioned in the inter/ versions or help pages,
> so I'm not sure if my guess for its purpose is correct. Regardless, rip
> away!
>
>
> > 3) some units are map units by default, where some are percent, some
> > inches. It would be IMHO great, if the user would have allways to
> > specify, which units she would like to use (without enything, it would
> > be map units), example:
> ..
> > currently, only some instructions are supporting %
>
> Yes, this can be annoying. This is wish # 3335
>   https://intevation.de/rt/webrt?serial_num=3335
>
> For general purpose commands like placing text on the page I have tried
> to add placement by all three modes where I could. (or at least allow
> one of the comments/labels/text commands to get the job done using the
> reference system needed)
>
> There is another inconsistency in that some instructions refer to
> location on the page (usually in inches; eg legend, mapinfo), while
> other instructions refer to location in and around the map box (usually
> in percent or map coordinates; eg rectangle, text). Percentages greater
> or less than 0-100 are usually ok for placing text elsewhere on the page
> than in the map box (eg 115% height).
>
> So it is not random which commands have inches, and which have {percent
> or map coordinates}, it just seems like that. :)
>
> Presumably any GUI WYSIWYG tool could do all the units conversion math
> for you when creating the instructions file. (short pain for the GUI
> programmer, but then invisible)
>
>
> > 4) placenemnt should be allways specified with "where" keyword
>
> Careful, "where" is used for vector SQL queries too.
>
> > 5) text or other value should be allways specified with "value"
> > keyword:
> > 6) file (map) names should be allways specified with "name" keyword
>
> These are something that should wait for a full rewrite.
>
>
> Glynn:
> > 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.
>
> I agree. My plan was to have the new wxPython ps.map GUI worry about all
> the oddities in the ps.map controls and leave ps.map as it is. It may
> be odd, but it is fully functional and well tested and that is worth a
> lot.
>
> http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map
>
> If you wish to reimplement ps.map, as Glynn says you are best to start
> over from the beginning and call it ps/ps.something_else. It would be
> a real pain to have to rewrite years of carefully constructed ps.map
> templates. Straight GUI -> PostScript, skip C?
>
> I understand that it is a pain for writing the GUI to have to deal with
> the weird ways of ps.map, and I support adding missing % placement to
> any instruction that currently only takes map coordinates (if any still
> exist). I'm not so sure about mixing inches with percent (of page), even
> though this is annonying. Then you mix percent of page vs percent of map
> box, which is even more confusing.
>
>
> Hamish
>
> ps - I found a nice 10 minute Python tutorial [for programmers of other
> languages] that covers the basics,
>   http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming
>


-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub